* Re: git bug/feature request
From: gapon @ 2007-11-27 11:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0711270321q6f70554at177ade878448b9fc@mail.gmail.com>
as i wrote in my first email - i know that this is not "correct" scenario (i
don't and won't use it anywhere) - but the git's behaviour is in such case
confusing, at least for me
just for clarification - my email wasn't about how to push or create shared
repository - it was just about what i have discovered while playing with
different scms
gapon
Dne úterý 27 listopadu 2007 Alex Riesen napsal(a):
> On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> > hi all,
> > first of all i don't know if there's a bugzilla or something similar for
> > git - i have found just this email (on http://git.or.cz/ webpage).
> >
> > i have discovered "weird" behaviour of git in this scenario*:
> > - user A is working in repo A
> > - user B clones repo A
> > - user B makes some changes, commits, pushes
> > - user A makes some changes, git status (no info about new commit in his
> > repo from user B but it's probably ok i'd say - but some of my files are
> > marked as changed and already added to index but i haven't changed them
> > - that's confusing, isn't it?)
> > - user A can commit his changes => shouldn't be there any
> > info/message/warning displayed? it would be helpful to have here some
> > info about "foreign commit" in the repo or something like this
>
> If you share a repository with someone else, you better use different
> branches. What's happened is that user B changed the branch the
> user A was working on (strictly speaking, the B-user changed the
> reference A-user used as HEAD at the moment).
>
> Just have the B-user push his/hers changes on something else,
> not the master of the parent repository. For instance, B-user can
> add a "push"-line to his origin remote which redirects its pushes
> somewhere else:
>
> git config remote.origin.push 'refs/heads/*:refs/heads/B-user/*'
>
> Or just use a dedicated shared repo where no one works in.
> See also Documentation/config.txt, and the man page of git-push.
^ permalink raw reply
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-27 11:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20071127020842.GN14735@spearce.org>
Hi,
On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > This program dumps (parts of) a git repository in the format that
> > fast-import understands.
> ...
> > +-------------------------------------------------------------------
> > +$ git fast-export --all | (cd /empty/repository && git fast-import)
> > +-------------------------------------------------------------------
> > +
> > +This will export the whole repository and import it into the existing
> > +empty repository. Except for reencoding commits that are not in
> > +UTF-8, it would be a one-to-one mirror.
>
> WTF?
>
> Why are you reencoding the commits on output in fast-export? Why aren't
> you dumping them raw to the stream? fast-import takes them raw. Oh, it
> doesn't have a way to set the encoding header. DOH.
Not only that... FTFD:
~ Commit messages are free-form and are not interpreted by Git.
~ Currently they must be encoded in UTF-8, as fast-import does not permit
~ other encodings to be specified.
So the documentation stated very much that I _had_ to do it that way.
> I think this should be prefixed by fast-import patch to teach it
> something like "encoding N" as a subcommand of commit, so that you can
> feed data in a non UTF-8 encoding and get it to include the proper
> encoding header in the commit object it creates. That way a pipeline
> like the above really does create a duplicate repository, with the same
> commit SHA-1s, even if the commits weren't in UTF-8.
IMHO it's not worth that hassle. People who want to use fast-import
usually want something fast which works, and not bother with specifying
encodings.
Further, if you go down that road, some people will want to be able to say
"that commit is KOI-8, this one is UTF-8, and the third is encoded in
pre-Christian Tibetan runes."
But maybe I am wrong.
Ciao,
Dscho
^ permalink raw reply
* Re: git bug/feature request
From: Jakub Narebski @ 2007-11-27 11:30 UTC (permalink / raw)
To: git
In-Reply-To: <200711271127.41161.gapon007@gmail.com>
gapon wrote:
> hi all,
> first of all i don't know if there's a bugzilla or something similar
> for git - i have found just this email (on http://git.or.cz/ webpage).
There isn't any bug tracker for git. Use git mailing list for bug
reports and feature requests.
> i have discovered "weird" behaviour of git in this scenario*:
> - user A is working in repo A
> - user B clones repo A
> - user B makes some changes, commits, pushes
Do not push into checked out branch!
> - user A makes some changes, git status (no info about new commit
> in his repo from user B but it's probably ok i'd say - but some
> of my files are marked as changed and already added to index
> but i haven't changed them - that's confusing, isn't it?)
> - user A can commit his changes => shouldn't be there any
> info/message/warning displayed? it would be helpful to have
> here some info about "foreign commit" in the repo or something
> like this
Perhaps there should. There was some idea and even preliminary
implementation of BASE check, but IIRC it was deemed too complicated,
and encouraging wrong workflow.
Besides, even with the check, pushing into checked out branch can quite
easily lead either to loosing (or at least vanishing) some history,
or problems with pushing.
> * yes, i know that this scenario is "incorrect" but... it's possible and
> therefore i think it should be somehow handled - i tried a similar one
> with hg and bzr and i like their behaviour more
IIRC we strongly discourage in documentation to push into checked out
branch. Either use bare repository for communication (it allows for
example for got for "ideal patch series" by rewriting history _before
publishing (pushing)_ and for communication with more than one
chosen developer), or push into _remotes_, not into heads.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-27 11:25 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Shawn O. Pearce, hanwen, git
In-Reply-To: <20071127101614.GB26072@diana.vm.bytemark.co.uk>
Hi,
On Tue, 27 Nov 2007, Karl Hasselstr?m wrote:
> On 2007-11-26 16:48:14 +0000, Johannes Schindelin wrote:
>
> > On Sun, 25 Nov 2007, Karl Hasselstr?m wrote:
> >
> > > On 2007-11-23 15:59:58 -0500, Shawn O. Pearce wrote:
> > >
> > > > I have been considering creating a "git-gui daemon" process that
> > > > links to libgit.a and can be driven bidirectionally through its
> > > > stdin/stdout. Based on git-fast-export, sorta. But I haven't even
> > > > started it...
> > > >
> > > > But the idea is sort of what Han-Wen wants. Why should I fork
> > > > rev-parse to get a ref value? Or update-ref to change one?
> > >
> > > Obviously, something like this would be very valuable for StGit as
> > > well.
> >
> > Could you be a little more specific _what_ you want to do, and _how_
> > this could be done with fast-export | fast-import?
>
> Currently, a single StGit command can result in quite a few invocations
> of git-cat-file, for example, each of which forks off a new process. If
> it could start just one daemon such as Shawn proposed, and feed it
> simple questions and commands about blobs, trees, commits, and refs,
> that would probably be quite a lot faster.
>
> From what I understand, this is not something that would fit a
> fast-export | fast-import pipeline. Which is why I didn't take the time
> to elaborate on (or indeed find out) exactly which commands StGit would
> like such a daemon to support.
>
> By the way: one command one _would_ likely want in the daemon is "list
> modified files". Being long-lived (not when driven by StGit, perhaps,
> but definitely when driven by git-gui or qgit), the daemon would be able
> to use inotify for that.
Ah, so you would like something like "git --interactive"? This is indeed
a completely different scope than the fast-export thingie, which is meant
as kind of a mysqldump tool. Indeed, you could use it even as a (kind of
a) stash of the repo instead of the working tree.
Ciao,
Dscho
^ permalink raw reply
* Re: git bug/feature request
From: Alex Riesen @ 2007-11-27 11:21 UTC (permalink / raw)
To: gapon; +Cc: git
In-Reply-To: <200711271127.41161.gapon007@gmail.com>
On 27/11/2007, gapon <gapon007@gmail.com> wrote:
> hi all,
> first of all i don't know if there's a bugzilla or something similar for git -
> i have found just this email (on http://git.or.cz/ webpage).
>
> i have discovered "weird" behaviour of git in this scenario*:
> - user A is working in repo A
> - user B clones repo A
> - user B makes some changes, commits, pushes
> - user A makes some changes, git status (no info about new commit in his repo
> from user B but it's probably ok i'd say - but some of my files are marked as
> changed and already added to index but i haven't changed them - that's
> confusing, isn't it?)
> - user A can commit his changes => shouldn't be there any info/message/warning
> displayed? it would be helpful to have here some info about "foreign commit"
> in the repo or something like this
If you share a repository with someone else, you better use different
branches. What's happened is that user B changed the branch the
user A was working on (strictly speaking, the B-user changed the
reference A-user used as HEAD at the moment).
Just have the B-user push his/hers changes on something else,
not the master of the parent repository. For instance, B-user can
add a "push"-line to his origin remote which redirects its pushes
somewhere else:
git config remote.origin.push 'refs/heads/*:refs/heads/B-user/*'
Or just use a dedicated shared repo where no one works in.
See also Documentation/config.txt, and the man page of git-push.
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --cached to operate only on index
From: Johannes Schindelin @ 2007-11-27 11:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano, Kristian Høgsberg
In-Reply-To: <81b0412b0711270254i58be4d2fi5021767d99fcb753@mail.gmail.com>
Hi,
[commenting on the patch is a little cumbersome when the mailer does not
quote it for you...]
On Tue, 27 Nov 2007, Alex Riesen wrote:
@@ -550,6 +557,8 @@ static int parse_and_validate_options(int argc, const char *argv[])
free(enc);
}
+ if (all)
+ cached_only = 0;
if (!!also + !!only + !!all + !!interactive > 1)
die("Only one of --include/--only/--all/--interactive can be used.");
if (argc == 0 && (also || (only && !amend)))
My reply> I would rather add another !!cached_only to the existing if().
@@ -678,7 +688,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
if (!prepare_log_message(index_file, prefix) && !in_merge) {
- run_status(stdout, index_file, prefix);
+ if (!cached_only)
+ run_status(stdout, index_file, prefix);
rollback_index_files();
unlink(commit_editmsg);
return 1;
My reply> Would it not make more sense to avoid run_status() when no_edit?
My reply> Ciao,
My reply> Dscho
^ permalink raw reply
* Re: git bug/feature request
From: gapon @ 2007-11-27 11:16 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git
In-Reply-To: <7A14A564-C424-4ACC-A860-A11DCC38C9A1@lrde.epita.fr>
bzr:
while pushing, bzr tries to merge into the current working copy (of A)
-> all changes are applied or conflicts occure
hg:
while pushing, neither merge nor info message, but new head (branch) is
created in repo A - so then in A you can commit your changes but it's
different head (repo A has more heads, use hg heads to list them)
btw i filed and enhancement for hg, to let user know that there are more heads
in the repo (you have to use hg log or hg heads to discover that someone else
has pushed into your repo and hg merge to merge them)
gapon
Dne úterý 27 listopadu 2007 Benoit Sigoure napsal(a):
> On Nov 27, 2007, at 11:27 AM, gapon wrote:
> > * yes, i know that this scenario is "incorrect" but... it's
> > possible and
> > therefore i think it should be somehow handled - i tried a similar
> > one with
> > hg and bzr and i like their behaviour more
>
> Would you mind describing the behavior of hg and bzr in this case?
>
> I was also bitten by this "feature" of Git. Until I decided to put a
> bare repo in between and push my commits there.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-27 11:12 UTC (permalink / raw)
To: しらいしななこ
Cc: Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <200711270622.lAR6MFXQ010010@mi0.bluebottle.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 775 bytes --]
Hi,
On Tue, 27 Nov 2007, しらいしななこ wrote:
> Quoting Andreas Ericsson <ae@op5.se>:
>
> > "git pull --rebase" already has an implementation. Dscho cooked one up
> > which I've been using since then. It works nicely.
>
> What is the reason that the option was not added to the official git?
> Was it coded poorly, buggy or were there some other issues?
It is very well possible that it was coded poorly ;-)
The main reason, I believe, was that some old-timers who know the
implications said that it would encourage a wrong workflow. One thing
that could go possibly wrong, for example, is to rebase commits that you
already published.
So AFAICT it was deemed not only giving people rope, but making that rope
look like a necklace to them.
Ciao,
Dscho
^ permalink raw reply
* Re: git bug/feature request
From: Benoit Sigoure @ 2007-11-27 10:57 UTC (permalink / raw)
To: gapon; +Cc: git
In-Reply-To: <200711271127.41161.gapon007@gmail.com>
On Nov 27, 2007, at 11:27 AM, gapon wrote:
> * yes, i know that this scenario is "incorrect" but... it's
> possible and
> therefore i think it should be somehow handled - i tried a similar
> one with
> hg and bzr and i like their behaviour more
Would you mind describing the behavior of hg and bzr in this case?
I was also bitten by this "feature" of Git. Until I decided to put a
bare repo in between and push my commits there.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* [PATCH] builtin-commit: add --cached to operate only on index
From: Alex Riesen @ 2007-11-27 10:54 UTC (permalink / raw)
To: Git Mailing List
Cc: Junio C Hamano, Johannes Schindelin, Kristian Høgsberg
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
The option is to enable operation exclusively on the index, without touching
working tree. Besides speeding up commit process on performance-challenged
platforms it also has to ensure that the index is commited exactly how
user sees it.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-commit.c | 15 +++++++++++++--
t/t7502-commit.sh | 30 ++++++++++++++++++++++++++++++
wt-status.c | 6 ++++--
wt-status.h | 1 +
4 files changed, 48 insertions(+), 4 deletions(-)
Triggered by perpetual Windows/Cygwin problems.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-cached-to-builtin-commit-operate-only-on-inde.patch --]
[-- Type: text/x-patch; name=0001-Add-cached-to-builtin-commit-operate-only-on-inde.patch, Size: 4642 bytes --]
From b7ccb6ef94fe8ed7e9ad232ba9ac772008b2b94f Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 27 Nov 2007 11:46:39 +0100
Subject: [PATCH] builtin-commit: add --cached to operate only on index
The option is to enable operation exclusively on the index, without touching
working tree. Besides speeding up commit process on performance-challenged
platforms it also has to ensure that the index is commited exactly how
user sees it.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-commit.c | 15 +++++++++++++--
t/t7502-commit.sh | 30 ++++++++++++++++++++++++++++++
wt-status.c | 6 ++++--
wt-status.h | 1 +
4 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index a35881e..6aa459e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -44,6 +44,7 @@ static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, untracked_files, no_verify;
static int no_edit, initial_commit, in_merge;
+static int cached_only;
const char *only_include_assumed;
struct strbuf message;
@@ -82,6 +83,7 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN('n', "no-verify", &no_verify, "bypass pre-commit hook"),
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
OPT_BOOLEAN(0, "untracked-files", &untracked_files, "show all untracked files"),
+ OPT_BOOLEAN(0, "cached", &cached_only, "consider only cached files"),
OPT_END()
};
@@ -164,6 +166,10 @@ static char *prepare_index(const char **files, const char *prefix)
struct path_list partial;
const char **pathspec = NULL;
+ if (cached_only) {
+ commit_style = COMMIT_AS_IS;
+ return get_index_file();
+ }
if (interactive) {
interactive_add();
commit_style = COMMIT_AS_IS;
@@ -287,6 +293,7 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix)
}
s.verbose = verbose;
s.untracked = untracked_files;
+ s.cached_only = cached_only;
s.index_file = index_file;
s.fp = fp;
@@ -550,6 +557,8 @@ static int parse_and_validate_options(int argc, const char *argv[])
free(enc);
}
+ if (all)
+ cached_only = 0;
if (!!also + !!only + !!all + !!interactive > 1)
die("Only one of --include/--only/--all/--interactive can be used.");
if (argc == 0 && (also || (only && !amend)))
@@ -560,11 +569,12 @@ static int parse_and_validate_options(int argc, const char *argv[])
only_include_assumed = "Explicit paths specified without -i nor -o; assuming --only paths...";
also = 0;
}
-
if (all && argc > 0)
die("Paths with -a does not make sense.");
else if (interactive && argc > 0)
die("Paths with --interactive does not make sense.");
+ else if (cached_only && argc > 0)
+ die("Paths with --cached does not make sense.");
return argc;
}
@@ -678,7 +688,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
if (!prepare_log_message(index_file, prefix) && !in_merge) {
- run_status(stdout, index_file, prefix);
+ if (!cached_only)
+ run_status(stdout, index_file, prefix);
rollback_index_files();
unlink(commit_editmsg);
return 1;
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 21ac785..bcfadd7 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -89,4 +89,34 @@ test_expect_success 'verbose' '
'
+test_expect_success 'cached only' '
+
+ git reset --hard &&
+ echo >file1 &&
+ echo >file2 &&
+ git add file1 file2 &&
+ git commit --cached -mcached1
+
+'
+
+test_expect_success 'cached only (ignore uncached)' '
+
+ git reset --hard &&
+ echo file1 >file1 &&
+ echo file2 >file2 &&
+ git add file1 &&
+ git status --cached | grep file2
+ test $? != 0
+
+'
+
+test_expect_success 'do not commit if index unchanged' '
+
+ git reset --hard &&
+ echo change >file1 &&
+ git commit --cached -mcached2
+ test $? != 0
+
+'
+
test_done
diff --git a/wt-status.c b/wt-status.c
index 0e0439f..9306491 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -367,8 +367,10 @@ void wt_status_print(struct wt_status *s)
wt_status_print_updated(s);
}
- wt_status_print_changed(s);
- wt_status_print_untracked(s);
+ if (!s->cached_only) {
+ wt_status_print_changed(s);
+ wt_status_print_untracked(s);
+ }
if (s->verbose && !s->is_initial)
wt_status_print_verbose(s);
diff --git a/wt-status.h b/wt-status.h
index 225fb4d..f50e780 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -17,6 +17,7 @@ struct wt_status {
int verbose;
int amend;
int untracked;
+ int cached_only;
/* These are computed during processing of the individual sections */
int commitable;
int workdir_dirty;
--
1.5.3.6.1008.gbaccf
^ permalink raw reply related
* Re: QGit: Shrink used memory with custom git log format
From: Johannes Schindelin @ 2007-11-27 10:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Marco Costalba, Git Mailing List
In-Reply-To: <20071127015248.GK14735@spearce.org>
Hi,
On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> Marco Costalba <mcostalba@gmail.com> wrote:
> > Now instead of --pretty=raw a custom made --pretty=format is given,
> > this shrinks loaded data of 30% (17MB less on Linux tree) and gives a
> > good speed up when you are low on memory (especially on big repos)
> >
> > Next step _would_ be to load log message body on demand (another 50%
> > reduction) but this has two drawbacks:
> >
> > (1) Text search/filter on log message would be broken
> >
> > (2) Slower to browse through revisions because for each revision an
> > additional git-rev-list /git-log command should be executed to read
> > the body
> >
> > The second point is worsted by the fact that it is not possible to
> > keep a command running and "open" like as example git-diff-tree
> > --stdin and feed with additional revision's sha when needed. Avoiding
> > the burden to startup a new process each time to read a new log
> > message given an sha would let the answer much more quick especially
> > on lesser OS's
> >
> > Indeed there is a git-rev-list --stdin option but with different
> > behaviour from git-diff-tree --stdin and not suitable for this.
>
> There was a proposed patch for git-cat-file that would let you run
> it in a --stdin mode; the git-svn folks wanted this to speed up
> fetching raw objects from the repository. That may help as you
> could get commit bodies (in raw format - not reencoded format!)
> quite efficiently.
>
> Otherwise I think what you really want here is a libgit that you can
> link into your process and that can efficiently inflate an object
> on demand for you. Like the work Luiz was working on this past
> summer for GSOC. Lots of downsides to that current tree though...
> like die() kills the GUI...
But then, die() calls die_routine, which you can override. And C++ has
this funny exception mechanism which just begs to be used here. The only
thing you need to add is a way to flush all singletons like the object
array.
Ciao,
Dscho
^ permalink raw reply
* git bug/feature request
From: gapon @ 2007-11-27 10:27 UTC (permalink / raw)
To: git
hi all,
first of all i don't know if there's a bugzilla or something similar for git -
i have found just this email (on http://git.or.cz/ webpage).
i have discovered "weird" behaviour of git in this scenario*:
- user A is working in repo A
- user B clones repo A
- user B makes some changes, commits, pushes
- user A makes some changes, git status (no info about new commit in his repo
from user B but it's probably ok i'd say - but some of my files are marked as
changed and already added to index but i haven't changed them - that's
confusing, isn't it?)
- user A can commit his changes => shouldn't be there any info/message/warning
displayed? it would be helpful to have here some info about "foreign commit"
in the repo or something like this
hmm?
thanks for git, it's simply the best one!
gapon
* yes, i know that this scenario is "incorrect" but... it's possible and
therefore i think it should be somehow handled - i tried a similar one with
hg and bzr and i like their behaviour more
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Karl Hasselström @ 2007-11-27 10:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, hanwen, git
In-Reply-To: <Pine.LNX.4.64.0711261647400.27959@racer.site>
On 2007-11-26 16:48:14 +0000, Johannes Schindelin wrote:
> On Sun, 25 Nov 2007, Karl Hasselström wrote:
>
> > On 2007-11-23 15:59:58 -0500, Shawn O. Pearce wrote:
> >
> > > I have been considering creating a "git-gui daemon" process that
> > > links to libgit.a and can be driven bidirectionally through its
> > > stdin/stdout. Based on git-fast-export, sorta. But I haven't
> > > even started it...
> > >
> > > But the idea is sort of what Han-Wen wants. Why should I fork
> > > rev-parse to get a ref value? Or update-ref to change one?
> >
> > Obviously, something like this would be very valuable for StGit as
> > well.
>
> Could you be a little more specific _what_ you want to do, and _how_
> this could be done with fast-export | fast-import?
Currently, a single StGit command can result in quite a few
invocations of git-cat-file, for example, each of which forks off a
new process. If it could start just one daemon such as Shawn proposed,
and feed it simple questions and commands about blobs, trees, commits,
and refs, that would probably be quite a lot faster.
From what I understand, this is not something that would fit a
fast-export | fast-import pipeline. Which is why I didn't take the
time to elaborate on (or indeed find out) exactly which commands StGit
would like such a daemon to support.
By the way: one command one _would_ likely want in the daemon is "list
modified files". Being long-lived (not when driven by StGit, perhaps,
but definitely when driven by git-gui or qgit), the daemon would be
able to use inotify for that.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Jeff King @ 2007-11-27 10:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <figp6f$onj$1@ger.gmane.org>
On Tue, Nov 27, 2007 at 10:49:03AM +0100, Jakub Narebski wrote:
> If I remember correctly /bin/sh on Solaris cannot be used because
> of other issues (like $(...) and such).
BTW, your new mail/news gateway solution seems to send two messages. I
got one that was addressed _only_ to me, and then this one came to the
list (and was addressed only to the list). That means that I had to
manually re-add the list when responding to the first one (or just
assume that you responded to me off-list). Personally, I think this is
worse than the previous "send only to the list" behavior because senders
are inevitably going to fail to re-add the list (but then, I was never
as bothered by others not to be cc'd in the first place).
-Peff
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Jakub Narebski @ 2007-11-27 9:49 UTC (permalink / raw)
To: git
In-Reply-To: <20071127094639.GC3571@sigill.intra.peff.net>
Jeff King wrote:
> On Tue, Nov 27, 2007 at 09:31:06AM +0100, Johannes Sixt wrote:
>
>> Isn't this a bashism? Should be:
>>
>> _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
>> export _GIT_CHERRY_PICK_HELP
>>
>> (and the second instance of this as well, of course)
>
> No, it's in POSIX:
>
> http://www.opengroup.org/onlinepubs/009695399/utilities/export.html
>
> However, I'm sure you will be shocked to learn that /bin/sh on Solaris
> doesn't understand it:
>
> $ export foo=bar
> foo=bar: is not an identifier
If I remember correctly /bin/sh on Solaris cannot be used because
of other issues (like $(...) and such).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Jeff King @ 2007-11-27 9:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <figp6f$onj$1@ger.gmane.org>
On Tue, Nov 27, 2007 at 10:49:03AM +0100, Jakub Narebski wrote:
> > However, I'm sure you will be shocked to learn that /bin/sh on Solaris
> > doesn't understand it:
> >
> > $ export foo=bar
> > foo=bar: is not an identifier
>
> If I remember correctly /bin/sh on Solaris cannot be used because
> of other issues (like $(...) and such).
Yes, my response was not "we can't use this" (because clearly we have
been for some time) but rather "look how crappy the Solaris shell is.
Maybe you were thinking of it?"
IOW, the construct is fine to the best of my knowledge.
-Peff
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Jeff King @ 2007-11-27 9:46 UTC (permalink / raw)
To: Johannes Sixt
Cc: Wincent Colaiuta, git, gitster, tsuna, Johannes.Schindelin,
mcostalba
In-Reply-To: <474BD5CA.7050407@viscovery.net>
On Tue, Nov 27, 2007 at 09:31:06AM +0100, Johannes Sixt wrote:
> Isn't this a bashism? Should be:
>
> _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
> export _GIT_CHERRY_PICK_HELP
>
> (and the second instance of this as well, of course)
No, it's in POSIX:
http://www.opengroup.org/onlinepubs/009695399/utilities/export.html
However, I'm sure you will be shocked to learn that /bin/sh on Solaris
doesn't understand it:
$ export foo=bar
foo=bar: is not an identifier
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-11-27 8:52 UTC (permalink / raw)
To: しらいしななこ
Cc: Andreas Ericsson, git
In-Reply-To: <200711270622.lAR6MFXR010010@mi0.bluebottle.com>
On Tue, 27 Nov 2007, しらいしななこ (Nanako Shiraishi) napisał:
> Quoting Andreas Ericsson <ae@op5.se>:
>
>> "git pull --rebase" already has an implementation. Dscho cooked one up
>> which I've been using since then. It works nicely.
>
> What is the reason that the option was not added to the official git?
> Was it coded poorly, buggy or were there some other issues?
There was no main (feature) git release since?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Wincent Colaiuta @ 2007-11-27 8:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster, tsuna, Johannes.Schindelin, mcostalba
In-Reply-To: <474BD5CA.7050407@viscovery.net>
El 27/11/2007, a las 9:31, Johannes Sixt escribió:
> Wincent Colaiuta schrieb:
>> + export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
>
> Isn't this a bashism? Should be:
>
> _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
> export _GIT_CHERRY_PICK_HELP
>
> (and the second instance of this as well, of course)
I wondered that myself before submitting the patch, but then saw that
the same pattern was used at other places as well:
git-clone.sh:
W=$(cd "$GIT_WORK_TREE" && pwd) && export GIT_WORK_TREE="$W"
git-filter-branch.sh:
export GIT_INDEX_FILE="$(pwd)/../index"
export GIT_COMMIT=$commit
export GIT_COMMIT="$sha1"
git-quiltimport.sh:
export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
export GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
export SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
So if this is a problem, those sites will need to be changed as well.
Cheers,
Wincent
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Andy Parkins @ 2007-11-27 8:45 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550711261125i92fb057i85d7217b18cd495d@mail.gmail.com>
Marco Costalba wrote:
> But...wait...Qt would require...(I'm scared to say!)... that awful,
> painful, hopeless thing called C++. Probably you didn't mean what you
> said ;-)
Actually although I like C++, that's not the reason, the reason is that Qt
is a significantly (IMHO) better toolkit than Tk. It's more cross platform
and looks a lot nicer. The fact that it's C++ is neither here nor there.
Personally I find these language wars a bit distasteful; to me programming
is programming - the language is a purely secondary point.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Johannes Sixt @ 2007-11-27 8:45 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: gitster, git
In-Reply-To: <1196119109-27483-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg schrieb:
> +test_expect_success 'add files using absolute path names' '
> +echo a >afile &&
> +echo b >bfile &&
> +git-add afile &&
> +git-add $(pwd)/bfile &&
Please use "$(pwd)/bfile" (d-quotes) throughout. Otherwise the test would
fail if conducted in a directory with spaces.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Johannes Sixt @ 2007-11-27 8:31 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, gitster, tsuna, Johannes.Schindelin, mcostalba
In-Reply-To: <1196111891-18518-1-git-send-email-win@wincent.com>
Wincent Colaiuta schrieb:
> + export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
Isn't this a bashism? Should be:
_GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
export _GIT_CHERRY_PICK_HELP
(and the second instance of this as well, of course)
-- Hannes
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: しらいしななこ @ 2007-11-27 6:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, git
Quoting Andreas Ericsson <ae@op5.se>:
> "git pull --rebase" already has an implementation. Dscho cooked one up
> which I've been using since then. It works nicely.
What is the reason that the option was not added to the official git? Was it coded poorly, buggy or were there some other issues?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Find out how you can get spam free email.
http://www.bluebottle.com/tag/3
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Shawn O. Pearce @ 2007-11-27 6:12 UTC (permalink / raw)
To: Dana How; +Cc: Nicolas Pitre, Jakub Narebski, git
In-Reply-To: <56b7f5510711262159x2e1fd4fdw8e914cb4a22376a1@mail.gmail.com>
Dana How <danahow@gmail.com> wrote:
> On Nov 26, 2007 8:58 PM, Nicolas Pitre <nico@cam.org> wrote:
> >
> > It is a bit cumbersome indeed, but I'm afraid we're really stuck with it
> > since every object SHA1 depends on that format.
>
> Yes, now I remember: this was the same argument you used to
> convince me that losing the "new" (deprecated) loose format was OK.
>
> However, if we changed
> WRITE(DEFLATE(SHA1("$type $size\0$data")))
> (where SHA1(x) = x but has the side-effect of updating the SHA-1)
> to
> WRITE($pack_style_object_header)
> SHA1("$type $size\0")
> WRITE(DEFLATE(SHA1($data)))
> then the SHA-1 result is the same but we get the pack-style header,
> and blobs can be sucked straight into packs when not deltified.
> The SHA-1 result is still usable at the end to rename the temporary
> loose object file
> (and put it in the correct xx subdirectory).
Hah. That's exactly what the "new" (deprecated) format was, and what
its code for creating such objects looked like in sha1_file.c. :-)
--
Shawn.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Dana How @ 2007-11-27 5:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, Jakub Narebski, git, danahow
In-Reply-To: <alpine.LFD.0.99999.0711262346410.9605@xanadu.home>
On Nov 26, 2007 8:58 PM, Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> > - Loose objects storage is difficult to work with
> >
> > The standard loose object format of DEFLATE("$type $size\0$data")
> > makes it harder to work with as you need to inflate at least
> > part of the object just to see what the hell it is or how big
> > its final output buffer needs to be.
>
> It is a bit cumbersome indeed, but I'm afraid we're really stuck with it
> since every object SHA1 depends on that format.
Yes, now I remember: this was the same argument you used to
convince me that losing the "new" (deprecated) loose format was OK.
However, if we changed
WRITE(DEFLATE(SHA1("$type $size\0$data")))
(where SHA1(x) = x but has the side-effect of updating the SHA-1)
to
WRITE($pack_style_object_header)
SHA1("$type $size\0")
WRITE(DEFLATE(SHA1($data)))
then the SHA-1 result is the same but we get the pack-style header,
and blobs can be sucked straight into packs when not deltified.
The SHA-1 result is still usable at the end to rename the temporary
loose object file
(and put it in the correct xx subdirectory).
Because we can't change the SHA-1 result we unfortunately can
never drop the 2nd call above [this is something that could
have been different, to respond to the email that started this thread].
You didn't like the duplication between the 1st and 2nd call,
but I can't say I see that as a big deal.
> > It also makes it very hard to stream into a packfile if you have
> > determined its not worth creating a delta for the object (or no
> > suitable delta base is available).
> >
> > The new (now deprecated) loose object format that was based on
> > the packfile header format simplified this and made it much
> > easier to work with.
>
> Not really. Since separate zlib compression levels for loose objects
> and packed objects were introduced, there was a bunch of correctness
> issues. What do you do when both compression levels are different?
> Sometimes ignore them, sometimes not? Because the default loose object
> compression level is about speed and the default pack compression level
> is about good space reduction, the correct thing to do by default would
> have been to always decompress and recompress anyway when copying an
> otherwise unmodified loose object into a pack.
Not exactly. I did think about this. When you are packing to stdout,
and only sending the resulting packfile locally, you don't want to
bother with recompressing everything. [This is the "workgroup" case
that concerns me.] Other cases, sure,
recompression could help (e.g., packing to a file means the file
will probably be around for a while, so you want to recompress
if the levels are unequal; and you probably want to recompress
as well if the packfile will be sent over a "slow" link).
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ 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