* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-20 13:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20080720130407.GF10347@genesis.frugalware.org>
Hi,
On Sun, 20 Jul 2008, Miklos Vajna wrote:
> First, currently you can specify multiple strategies in the config
> (pull.twohead, pull.octopus) using a space separated list.
Oh, I did not mean to change that. I just misremembered.
> Second, we could allow custom strategies, as we started to discuss here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684
In my opinion, this would make it easier for interested parties to start
implementing that blame-based merge strategy I mentioned.
> Third, it would be nice to allow passing extra parameter(s) to the
> backends, but I do not know what concept is the best here. The
> strategy1=foo,stategy2=bar limits the input to a single string. Is that
> enough? Given that recursive=theirs was considered harmful, we don't
> have too much examples; for subtree the only parameter I could think of
> is the path, so a string there is enough.
>
> However, further strategies, like blame, could take more parameters,
> like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-)
The common solution is like with gcc's -Wl option, which translates
commata into spaces, like so: "-Wl,--machine,i386" is added as "--machine
i386" to the linker command line.
Our own cvsimport implements the same principle:
$ git cvsimport -p -b,HEAD
will only update the main branch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-merge.c: Fix option parsing
From: Miklos Vajna @ 2008-07-20 13:08 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, Junio C Hamano
In-Reply-To: <200807201434.47545.barra_cuda@katamail.com>
[-- Attachment #1: Type: text/plain, Size: 281 bytes --]
On Sun, Jul 20, 2008 at 02:34:47PM +0200, Michele Ballabio <barra_cuda@katamail.com> wrote:
> Now "git merge -m" needs a message, and errors out with the usage
> text if none is given.
> This way, t7600-merge.sh is fixed.
Thanks, I was about to fix this, but you were faster. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Miklos Vajna @ 2008-07-20 13:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0807191311220.3305@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On Sat, Jul 19, 2008 at 01:19:46PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a
> viable way to go. And more intuitive than "-X".
>
> I'll just ask Miklos what he thinks of the idea, and to write the patch if
> he likes it, once he's back from the saddle. :-)
I think there are three steps here.
First, currently you can specify multiple strategies in the config
(pull.twohead, pull.octopus) using a space separated list. If we want to
change it to a coma-separated list, should we care about backwards
compatibility? There are tests for this, but it's undocumented (and my
patch to document it was rejected, saying we should not encourage people
to use it).
Second, we could allow custom strategies, as we started to discuss here:
http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684
Third, it would be nice to allow passing extra parameter(s) to the
backends, but I do not know what concept is the best here. The
strategy1=foo,stategy2=bar limits the input to a single string. Is that
enough? Given that recursive=theirs was considered harmful, we don't
have too much examples; for subtree the only parameter I could think of
is the path, so a string there is enough.
However, further strategies, like blame, could take more parameters,
like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Petr Baudis @ 2008-07-20 12:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Lea Wiemann, git, John Hawley
In-Reply-To: <alpine.DEB.1.00.0807201420500.3305@eeepc-johanness>
Hi,
On Sun, Jul 20, 2008 at 02:33:46PM +0200, Johannes Schindelin wrote:
> On Sun, 20 Jul 2008, Petr Baudis wrote:
>
> > On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
> >
> > > Pasky tried to convert all Perl scripts at once IIRC, and my numerous
> > > problems just _making_ the Git scripts led me to rewrite a few Perl
> > > scripts in C, so I could safely exclude the Perl scripts from my
> > > personal fork.
> >
> > I don't remember any concrete report of such problems ever reaching me;
> > exactly what trouble are you hitting with the Perl scripts using Git.pm?
> > I will be glad to try to fix it.
>
> They reached you:
>
> http://article.gmane.org/gmane.comp.version-control.git/23153
running Git in-place without correctly setting the prefix is not
supported anyway; git wrapper will still be using non-builtin commands
from the prefix location instead of your fresh build.
> http://thread.gmane.org/gmane.comp.version-control.git/22764/focus=22778
It seems I fixed this right away?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: git cvsimport and deleted files
From: Johannes Schindelin @ 2008-07-20 12:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18563.10979.379533.580413@cargo.ozlabs.ibm.com>
Hi,
On Sun, 20 Jul 2008, Paul Mackerras wrote:
> I just tried importing the CVS repository for a long-running project
> (ppp) into git using git cvsimport. It looks like git cvsimport
> doesn't notice when files have been deleted, so files that used to be
> present and were subsequently deleted are present in the git tree for
> the most recent commit.
I never had that problem. See
http://repo.or.cz/w/libvncserver.git?a=commit;h=8dead0759febaa7176507e1bde13ebd9d2a30720
for a commit that was imported with cvsimport.
So your issue must lie somewhere else.
BTW do you have the repository locally? Then you should import with
cvs2svn or parsecvs instead. These programs are both faster and more
accurate than cvsimport. And AFAIK you can use cvsimport on the generated
repositories to update them incrementally.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Jay Soffian @ 2008-07-20 12:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tarmigan, Junio C Hamano, git, Michael J Gruber
In-Reply-To: <alpine.DEB.1.00.0807201250530.3305@eeepc-johanness>
On Sun, Jul 20, 2008 at 6:56 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Two things:
>
> - add and commit are two _different_ operations, not only in name, but
> also in nature. The fact that "commit -a" calls "add" is a _pure_
> convenience. It does not change the fact that "add" and "commit" are
> completely, utterly different.
>
> - if you are a heavy user of "commit -a", chances are that your history is
> not really useful, because you committed unrelated changes accidentally
> in the same commit.
>
> The latter point, BTW, is the reason I _never_ teach the "-a" option
> (actually, I teach no option at all) in my first two Git lessons.
I don't like "commit -a" and never use it and wonder why a
short-option was wasted on it.
I do like the new "add -a" (thank you Junio) but I will rarely use it.
I had the "addremove" alias in my .gitconfig specifically because I
used it so infrequently that it was hard for me to remember when I did
need it. So I think that "add --addremove" would be fine and we don't
need to spend a short-option ("-a") on it.
Lastly, I point out that when I started with git, it became much
clearer when I began reading "git add" as "git stage". I think my
first alias was "staged => diff --cached". But I am someone who likes
to learn how the things I use work early on.
j.
^ permalink raw reply
* Re: [RFC variant 2 of 2] "needs update" considered harmful
From: Johannes Schindelin @ 2008-07-20 12:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20080720112957.GE32184@machine.or.cz>
Hi,
On Sun, 20 Jul 2008, Petr Baudis wrote:
> Scripts need to be modified for the reorganization anyway,
No. They do not, if the 1st variant is applied.
> and I'm not sure if there are any actually depening on this particular
> string.
That is the question, isn't it? You would never know. Many people,
strange as it sounds, do not write to this list when they encounter
problems with Git. They vent on their blogs, not giving us a chance, and
other people comment "Me too"s.
One of the most important features of Git used to be its scriptability,
and I think that many hackers just love Git for it, even new hackers.
So it is probably not unheard of that someone wrote an update hook or a
cronjob using the output of "update-index --refresh".
But those people are probably not on this list, or not following every
thread, or they even forgot how/that they implemented such a hook/cronjob.
Ergo: we would not know if scripts break. Until it is too late.
Ciao,
Dscho
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Johannes Schindelin @ 2008-07-20 12:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, Lea Wiemann, git, John Hawley
In-Reply-To: <20080720104935.GB10151@machine.or.cz>
Hi,
On Sun, 20 Jul 2008, Petr Baudis wrote:
> On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
>
> > Pasky tried to convert all Perl scripts at once IIRC, and my numerous
> > problems just _making_ the Git scripts led me to rewrite a few Perl
> > scripts in C, so I could safely exclude the Perl scripts from my
> > personal fork.
>
> I don't remember any concrete report of such problems ever reaching me;
> exactly what trouble are you hitting with the Perl scripts using Git.pm?
> I will be glad to try to fix it.
They reached you:
http://article.gmane.org/gmane.comp.version-control.git/23153
http://thread.gmane.org/gmane.comp.version-control.git/22764/focus=22778
Yes, those are very old mails, but they _do_ explain why the old Perl
scripts avoided Git.pm.
> > But your mention of git-add--interactive actually brings up my
> > pet-peeve: this script is the only Perl script needed for common
> > operations, i.e. the only reason msysGit has to ship bloated with
> > Perl.
>
> _Many_ people seem to be using git-svn, whether we like it or not. ;-)
Well, they will just stop using it on msysGit, since nobody fixes git-svn
on msysGit.
> Also, isn't git-send-mail rather commonly used? (I wouldn't know, me
> using stg mail.)
send-mail does not work on Windows. See
http://code.google.com/p/msysgit/issues/detail?id=27
Yes, you read correctly. The issue exists since almost the birth of
msysGit. Torgil seems to have stopped working on it altogether. Two
other people have "starred" the issue, wanting to be notified of fixes but
not wanting to work on them.
To me, it seems that either the Windows folk is a lazy bunch of bums, or
they just do not care enough. Or both.
Note: I want to express very loudly here that I do not count Hannes Sixt
as Windows folk. Even if he seems to like cmd.exe for some perverse
reason, it is undisputable that his effort, and his effort alone, brought
the MinGW port to where it is now.
To sum it up, I think we can safely remove Perl from the msysGit installer
once add--interactive is a builtin. The download will be substantially
smaller, and Perl on msysGit was never exactly a speed demon, so it's
probably a good change from several angles.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] builtin-merge.c: Fix option parsing
From: Michele Ballabio @ 2008-07-20 12:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Now "git merge -m" needs a message, and errors out with the usage
text if none is given.
This way, t7600-merge.sh is fixed.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-merge.c | 5 +++--
t/t7600-merge.sh | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 129b4e6..84a541d 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -68,10 +68,11 @@ static int option_parse_message(const struct option *opt,
if (unset)
strbuf_setlen(buf, 0);
- else {
+ else if (arg) {
strbuf_addf(buf, "%s\n\n", arg);
have_message = 1;
- }
+ } else
+ return error("switch `m' requires a value");
return 0;
}
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 26cf8dc..5eeb6c2 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -221,7 +221,7 @@ test_expect_success 'setup' '
test_debug 'gitk --all'
-test_expect_failure 'test option parsing' '
+test_expect_success 'test option parsing' '
test_must_fail git merge -$ c1 &&
test_must_fail git merge --no-such c1 &&
test_must_fail git merge -s foobar c1 &&
--
1.5.6.3
^ permalink raw reply related
* [PATCH] Teach 'git merge' that 'recur' merge strategy no longer exists
From: Miklos Vajna @ 2008-07-20 12:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <20080720192125.6117@nanako3.lavabit.com>
It co-existed with 'recursive' when rewriting it in C, but it no longer
available.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sun, Jul 20, 2008 at 07:21:25PM +0900, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> - { "stupid", 0 },
If we are at it, recur is also something unnecessary here.
builtin-merge.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 129b4e6..beba635 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -50,7 +50,6 @@ static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
static struct strategy all_strategy[] = {
- { "recur", NO_TRIVIAL },
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
{ "octopus", DEFAULT_OCTOPUS },
{ "resolve", 0 },
--
1.5.6.2.450.g8d367.dirty
^ permalink raw reply related
* git cvsimport and deleted files
From: Paul Mackerras @ 2008-07-20 12:09 UTC (permalink / raw)
To: git
I just tried importing the CVS repository for a long-running project
(ppp) into git using git cvsimport. It looks like git cvsimport
doesn't notice when files have been deleted, so files that used to be
present and were subsequently deleted are present in the git tree for
the most recent commit.
Is this a known problem? Is it a limitation of cvsps? I know that
cvs doesn't represent deletions explicitly anywhere, so I guess it's
not surprising, but it is a bit annoying.
Paul.
^ permalink raw reply
* Re: [RFC PATCH v2] Support gitlinks in fast-import.
From: Johannes Schindelin @ 2008-07-20 12:07 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Shawn O. Pearce
In-Reply-To: <200807191621.25654.angavrilov@gmail.com>
Hi,
On Sat, 19 Jul 2008, Alexander Gavrilov wrote:
> Links can be represented by two forms of the
> Modify command:
>
> M 160000 SHA1 some/path
>
> which sets the link target explicitly, or
>
> M 160000 :mark some/path
>
> where the mark refers to a commit. The latter
> form can be used by importing tools to build
> all submodules simultaneously in one physical
> repository, and then simply fetch them apart.
It seems that people like to do this, have their submodule branches in the
superproject. I wonder if we should bless this by installing an alternate
in the "git submodule init"ed submodules, or even do it during a "git
submodule update".
> + /* Links refer to objects in another repositories, so
s/another/other/
Thanks, especially for the tests,
Dscho
^ permalink raw reply
* Re: [PATCH] Enable git rev-list to parse --quiet
From: Nick Andrew @ 2008-07-20 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsjhc7kj.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 12:56:28AM -0700, Junio C Hamano wrote:
> Nick Andrew <nick@nick-andrew.net> writes:
>
> > ...Without
> > a working "--quiet" nor exit code I can pipe the output to "wc -l"
> > but is there a more efficient/reliable way to implement the requirement?
>
> Did you read the whole thread before asking the above question?
I took your answer to mean that I shouldn't be using git-rev-list
for this purpose, so I asked whether there's a better way to do
it. Johannes Schindelin gave a good answer to that.
> IOW, does this answer the above question?
>
> http://mid.gmane.org/7vy73zd8ok.fsf@gitster.siamese.dyndns.org
I'm not happy with that patch due to this:
static void finish_commit(struct commit *commit)
{
+ if (check_empty)
+ exit(0);
Exiting a process from within a callback function seems to me to violate
the principle of least surprise. If the return code should be zero then
the cmd_rev_list function should return zero, and run_command will
return zero and handle_internal_command will exit zero. There must be
a better way to avoid redundant processing for the empty set case.
Nick.
^ permalink raw reply
* Re: [PATCH] builtin-merge-recursive.c: make merge_recursive() static
From: Johannes Schindelin @ 2008-07-20 12:03 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Junio C Hamano
In-Reply-To: <20080720192127.6117@nanako3.lavabit.com>
Hi,
On Sun, 20 Jul 2008, Nanako Shiraishi wrote:
> This function is not used by any other file.
And I thought it would be, in a future version of builtin-merge...
Of course, we could apply this patch now, and revert it later, increasing
your commit count in the process :-)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] builtin-push.c: Cleanup - use OPT_BIT() and remove some variables
From: Michele Ballabio @ 2008-07-20 12:02 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-push.c | 29 ++++++++---------------------
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 03db28c..c1ed68d 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -14,7 +14,7 @@ static const char * const push_usage[] = {
NULL,
};
-static int thin, verbose;
+static int thin;
static const char *receivepack;
static const char **refspec;
@@ -84,7 +84,7 @@ static int do_push(const char *repo, int flags)
if (thin)
transport_set_option(transport, TRANS_OPT_THIN, "yes");
- if (verbose)
+ if (flags & TRANSPORT_PUSH_VERBOSE)
fprintf(stderr, "Pushing to %s\n", remote->url[i]);
err = transport_push(transport, refspec_nr, refspec, flags);
err |= transport_disconnect(transport);
@@ -101,22 +101,19 @@ static int do_push(const char *repo, int flags)
int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
- int all = 0;
- int mirror = 0;
- int dry_run = 0;
- int force = 0;
int tags = 0;
int rc;
const char *repo = NULL; /* default repository */
struct option options[] = {
- OPT__VERBOSE(&verbose),
+ OPT_BIT('v', "verbose", &flags, "be verbose", TRANSPORT_PUSH_VERBOSE),
OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
- OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
- OPT_BOOLEAN( 0 , "mirror", &mirror, "mirror all refs"),
+ OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
+ OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
+ (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
- OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
- OPT_BOOLEAN('f', "force", &force, "force updates"),
+ OPT_BIT( 0 , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
+ OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack program"),
@@ -125,18 +122,8 @@ int cmd_push(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, options, push_usage, 0);
- if (force)
- flags |= TRANSPORT_PUSH_FORCE;
- if (dry_run)
- flags |= TRANSPORT_PUSH_DRY_RUN;
- if (verbose)
- flags |= TRANSPORT_PUSH_VERBOSE;
if (tags)
add_refspec("refs/tags/*");
- if (all)
- flags |= TRANSPORT_PUSH_ALL;
- if (mirror)
- flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
if (argc > 0) {
repo = argv[0];
--
1.5.6.3
^ permalink raw reply related
* Re: [RFC variant 2 of 2] "needs update" considered harmful
From: Petr Baudis @ 2008-07-20 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ibhdmii.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 12:48:21AM -0700, Junio C Hamano wrote:
> "git update-index --refresh", "git reset" and "git add --refresh" have
> reported paths that have local modifications as "needs update" since the
> beginning of git.
>
> Although this is logically correct in that you need to update the index at
> that path before you can commit that change, it is now becoming more and
> more clear, especially with the continuous push for user friendliness
> since 1.5.0 series, that the message is suboptimal. After all, the change
> may be something the user might want to get rid of, and "updating" would
> be absolutely a wrong thing to do if that is the case.
>
> I prepared two alternatives to solve this. Both aim to reword the message
> to more neutral "locally modified".
>
> This patch is a more straightforward variant that changes the message not
> only for Porcelain commands ("add" and "reset") but also changes the
> output from the plumbing command "update-index".
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
I believe this is a good thing. Scripts need to be modified for the
reorganization anyway, and I'm not sure if there are any actually
depening on this particular string. I think having inconsistent error
messaging is worse in long term.
FWIW, looking at Cogito,
cg-Xlib: git-update-index --refresh | sed 's/needs update$/locally modified/'
is the only reference to this. ;-)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: What's in git.git (stable)
From: Lars Noschinski @ 2008-07-20 11:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsjhgvtn.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [08-07-20 03:59]:
>Lars Noschinski (2):
> cvsserver: Add support for packed refs
> cvsserver: Add cvs co -c support
Any specific reason why you did not merge the test for packed refs
support? Was it considered superfluous?
^ permalink raw reply
* Re: Suggestion: doc restructuring
From: Johannes Schindelin @ 2008-07-20 11:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git
In-Reply-To: <7vk5fhc6qo.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > So what I really would like is this: leave the plumbing pages as they
> > are, but enhance those pages that users (especially new ones) are
> > likely to see most often.
>
> Regarding the original "do we want to ever teach plumbing to new users?"
> issue, I suspect that, with sufficient enhancement to Porcelain, we
> might be able to reach a point where end users can work without ever
> touching a single plumbing command at all.
I just went back to the thread I mentioned earlier,
http://thread.gmane.org/gmane.comp.version-control.git/59935/focus=62021
and I did not find where you need plumbing.
> Perhaps move the plumbing documentation to section 3; just like Perl has
> DBI.3pm and friends there, /usr/share/man/man3/git-cat-file.3git will
> describe what scripts can do with the command.
But of course! I was wondering where to put it, but understanding
plumbing as a sort of library for shell scripts makes sense absolutely!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Johannes Schindelin @ 2008-07-20 10:56 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, git, Michael J Gruber, Jay Soffian
In-Reply-To: <905315640807192120k45b8c0e3k5b341e77c466dde@mail.gmail.com>
Hi,
On Sat, 19 Jul 2008, Tarmigan wrote:
> It's too bad that 'commit -a' and 'add -a' will have different
> meanings.
Two things:
- add and commit are two _different_ operations, not only in name, but
also in nature. The fact that "commit -a" calls "add" is a _pure_
convenience. It does not change the fact that "add" and "commit" are
completely, utterly different.
- if you are a heavy user of "commit -a", chances are that your history is
not really useful, because you committed unrelated changes accidentally
in the same commit.
The latter point, BTW, is the reason I _never_ teach the "-a" option
(actually, I teach no option at all) in my first two Git lessons.
Ciao,
Dscho
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Petr Baudis @ 2008-07-20 10:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Lea Wiemann, git, John Hawley
In-Reply-To: <alpine.DEB.1.00.0807201233010.3305@eeepc-johanness>
Hi,
On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
> You call that "worse"? Pasky tried to convert all Perl scripts at once
> IIRC, and my numerous problems just _making_ the Git scripts led me to
> rewrite a few Perl scripts in C, so I could safely exclude the Perl
> scripts from my personal fork.
I don't remember any concrete report of such problems ever reaching
me; exactly what trouble are you hitting with the Perl scripts using
Git.pm? I will be glad to try to fix it.
> I guess that it was this experience which prevented more of the old
> scripts from being converted.
>
> But your mention of git-add--interactive actually brings up my pet-peeve:
> this script is the only Perl script needed for common operations, i.e. the
> only reason msysGit has to ship bloated with Perl.
_Many_ people seem to be using git-svn, whether we like it or not. ;-)
Also, isn't git-send-mail rather commonly used? (I wouldn't know, me
using stg mail.)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Johannes Schindelin @ 2008-07-20 10:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, Lea Wiemann, git, John Hawley
In-Reply-To: <200807192254.24622.jnareb@gmail.com>
Hi,
On Sat, 19 Jul 2008, Jakub Narebski wrote:
> From git commands in Perl the following include "use Git" in their
> sources: git-cvsexportcommit, git-send-email, git-svn, and helper
> script git-add--interactive. There are Perl scripts which do not
> use Git.pm: git-archimport (which I think should be obsoleted or
> moved to contrib), git-cvsimport, git-cvsserver, git-relink. This
> means that half of Perl scripts use Git Perl API.
>
> The situation is worse for scripts in 'contrib/'. From those, only
> contrib/examples/git-remote.perl uses Git.pm; neither blameview,
> continuous, git-import and import-tars in fast-import, setgitperms
> and update-paranoid in hooks, stats, nor other Perl scripts in
> examples (git-rerere, git-svnimport) include "use Git".
You call that "worse"? Pasky tried to convert all Perl scripts at once
IIRC, and my numerous problems just _making_ the Git scripts led me to
rewrite a few Perl scripts in C, so I could safely exclude the Perl
scripts from my personal fork.
I guess that it was this experience which prevented more of the old
scripts from being converted.
But your mention of git-add--interactive actually brings up my pet-peeve:
this script is the only Perl script needed for common operations, i.e. the
only reason msysGit has to ship bloated with Perl.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-20 10:27 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: Keith Packard, git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <1216491512.3911.9.camel@pc7.dolda2000.com>
Hi,
On Sat, 19 Jul 2008, Fredrik Tolf wrote:
> On Sat, 2008-07-19 at 10:57 -0700, Keith Packard wrote:
> > On Sat, 2008-07-19 at 19:06 +0200, Fredrik Tolf wrote:
> > > By removing the DISPLAY env variable before forking, SSH
> > > can thus be forced into non-interactive mode, without any obvious
> > > ill effects.
> >
> > This will keep ssh-askpass from using any X-based password input
> > program.
>
> Ah, right. Would it be OK to add the `-x' flag to ssh instead?
I think this would be the correct way, together with "-T".
> I imagine that that might make git less portable to SSH implementations
> other than OpenSSH, but I don't know if that is considered a problem.
Well, this was to be expected, after what I wrote in response to 3. in
http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
Reality always catches up with you, and here again we see that plink and
other siblings of OpenSSH should be best handled with scripts, preferably
ones that strip out options they do not recognize.
IOW something like
-- snip --
#!/bin/bash
plinkopt=
while test $# != 0
do
case "$1" in
-p)
plinkopt="$plinkopt -P $2"
shift
;;
-*)
# unrecognized; strip out
;;
*)
break
;;
esac
shift
done
exec plink $plinkopt "$@"
-- snap --
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-merge -s theirs
From: Nanako Shiraishi @ 2008-07-20 10:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Sometimes people wonder why "-s ours" strategy exists but "-s theirs" does
not. The reason was explained on the mailing list recently:
Quoting Junio C Hamano <gitster@pobox.com>:
> One big problem "-s theirs" has, compared to the "reset to origin,
> discarding or setting aside the failed history" is that your 'master'
> history that your further development is based on will keep your failed
> crap in it forever if you did "-s theirs". Hopefully you will become a
> better programmer over time, and you may eventually have something worth
> sharing with the world near the tip of your master branch. When that
> happens, however, you _cannot_ offer your master branch to be pulled by
> the upstream, as the wider world will not be interested in your earlier
> mistakes at all.
This patch steals much code from "git-merge-resolve" to add "theirs"
strategy. Its purpose is to always fail and suggest using the preferred
command "git reset --hard the-other-commit".
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Makefile | 3 ++-
builtin-merge.c | 1 +
git-merge-theirs.sh | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+), 1 deletions(-)
create mode 100755 git-merge-theirs.sh
diff --git a/Makefile b/Makefile
index 2b670d7..22f699a 100644
--- a/Makefile
+++ b/Makefile
@@ -240,6 +240,7 @@ SCRIPT_SH += git-lost-found.sh
SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
SCRIPT_SH += git-merge-resolve.sh
+SCRIPT_SH += git-merge-theirs.sh
SCRIPT_SH += git-mergetool.sh
SCRIPT_SH += git-parse-remote.sh
SCRIPT_SH += git-pull.sh
@@ -1433,7 +1434,7 @@ check-docs::
do \
case "$$v" in \
git-merge-octopus | git-merge-ours | git-merge-recursive | \
- git-merge-resolve | git-merge-subtree | \
+ git-merge-resolve | git-merge-subtree | git-merge-theirs | \
git-fsck-objects | git-init-db | \
git-?*--?* ) continue ;; \
esac ; \
diff --git a/builtin-merge.c b/builtin-merge.c
index edc6016..8ed815b 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -55,6 +55,7 @@ static struct strategy all_strategy[] = {
{ "octopus", DEFAULT_OCTOPUS },
{ "resolve", 0 },
{ "ours", NO_FAST_FORWARD | NO_TRIVIAL },
+ { "theirs", NO_FAST_FORWARD | NO_TRIVIAL },
{ "subtree", NO_FAST_FORWARD | NO_TRIVIAL },
};
diff --git a/git-merge-theirs.sh b/git-merge-theirs.sh
new file mode 100755
index 0000000..e228d2b
--- /dev/null
+++ b/git-merge-theirs.sh
@@ -0,0 +1,34 @@
+#!/bin/sh
+
+# The first parameters up to -- are merge bases; the rest are heads.
+bases= head= remotes= sep_seen=
+for arg
+do
+ case ",$sep_seen,$head,$arg," in
+ *,--,)
+ sep_seen=yes
+ ;;
+ ,yes,,*)
+ head=$arg
+ ;;
+ ,yes,*)
+ remotes="$remotes$arg "
+ ;;
+ *)
+ bases="$bases$arg "
+ ;;
+ esac
+done
+
+# Give up if we are given two or more remotes -- not handling octopus.
+case "$remotes" in
+?*' '?*)
+ exit 2 ;;
+esac
+
+echo "If you wanted to say the other history is better than your history,"
+echo "use 'git reset --hard $remotes' instead."
+echo "If you want to keep a record of your failure, you can create a"
+echo "new branch from the current HEAD before running the reset command."
+
+exit 2
--
1.5.6.3
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] builtin-merge-recursive.c: make merge_recursive() static
From: Nanako Shiraishi @ 2008-07-20 10:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This function is not used by any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
builtin-merge-recursive.c | 2 +-
merge-recursive.h | 7 -------
2 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
index 1ab1945..553aa16 100644
--- a/builtin-merge-recursive.c
+++ b/builtin-merge-recursive.c
@@ -1247,7 +1247,7 @@ static struct commit_list *reverse_commit_list(struct commit_list *list)
* Merge the commits h1 and h2, return the resulting virtual
* commit object and a flag indicating the cleanness of the merge.
*/
-int merge_recursive(struct commit *h1,
+static int merge_recursive(struct commit *h1,
struct commit *h2,
const char *branch1,
const char *branch2,
diff --git a/merge-recursive.h b/merge-recursive.h
index f37630a..8924371 100644
--- a/merge-recursive.h
+++ b/merge-recursive.h
@@ -1,13 +1,6 @@
#ifndef MERGE_RECURSIVE_H
#define MERGE_RECURSIVE_H
-int merge_recursive(struct commit *h1,
- struct commit *h2,
- const char *branch1,
- const char *branch2,
- struct commit_list *ancestors,
- struct commit **result);
-
int merge_trees(struct tree *head,
struct tree *merge,
struct tree *common,
--
1.5.6.3
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] Teach "git-merge" that "stupid" merge strategy no longer exists
From: Nanako Shiraishi @ 2008-07-20 10:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Next release 1.6.0 will not have "stupid" merge strategy, but
"git merge -s confused origin" still includs it in the list of
available merge strategies.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
builtin-merge.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 129b4e6..edc6016 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -54,7 +54,6 @@ static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
{ "octopus", DEFAULT_OCTOPUS },
{ "resolve", 0 },
- { "stupid", 0 },
{ "ours", NO_FAST_FORWARD | NO_TRIVIAL },
{ "subtree", NO_FAST_FORWARD | NO_TRIVIAL },
};
--
1.5.6.3
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox