* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-11-03 5:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <7v3ai9226q.fsf@gitster.siamese.dyndns.org>
On Sun, 2008-11-02 at 14:27 -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> + * 'git push --matching' does what 'git push' does today (without
> >> + explicit configuration)
> >
> > I think this is reasonable even without other changes, just to override
> > any configuration.
>
> I don't. Can't you say "git push $there HEAD" these days? I vaguely
> recall that there is a way to configure push that way for people too lazy
> to type "origin HEAD" after "git push".
I don't think it's about laziness, it's more about making sure that
without specifying behaviour, the action of the command is conservative.
Pushing all matching refs is not conservative; it's "magic". And in my
experience, people get bitten by it, because they think, "ok, time to
push this branch", type "git push" and then a lot more than they
expected gets pushed.
I can see that some people want this behaviour by default; but to me
"push the current branch back to where it came from" seems like far more
a rational default for at least 90% of users.
Sam.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-11-03 6:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pierre Habouzit, Nicolas Pitre, Matthieu Moy, Theodore Tso, git
In-Reply-To: <7vabch22ou.fsf@gitster.siamese.dyndns.org>
On Sun, 2008-11-02 at 14:17 -0800, Junio C Hamano wrote:
> I'd agree that 'reset' is rather unfortunate. It very originally was all
> about the index (the "mixed" semantics, specifically "git reset" without
> any committish nor any pathspec, was the original use case) and nothing
> else. IOW, "I staged a wrong change, let's start over by discarding all
> staged changes". A logical extension to it is "git reset -- pathspec",
> IOW, "I know which paths I fubared, please reset only these paths, as
> other staged changes are Ok".
>
> So "reset <file>" is very much useful.
>
> Then 'reset' learned to also muck with HEAD, so "reset HEAD^" (still
> mixed, without any pathspec) can be used to amend the latest commit but
> without losing the state you would eventually want to arrive at. A
> logical extension to this was "git reset --hard HEAD^" to nuking instead
> of amending the mistake, and "git reset --soft HEAD^" to save the trouble
> of staging the changes when the mistake you are fixing is small compared
> to the entire change.
>
> "checkout [$committish] $path" came much later, and the command is all
> about index and files, and never about resetting HEAD. "checkout $path"
> does "reset --hard $path" (notice there is no $committish in either one)
> would have done, so we stopped enhancing the "reset" command in that
> direction.
Interesting.
I'm wondering whether the important thing here is not making a new
command, but simply deprecating "revert", and pointing the user to "git
reset" - then making sure that you can do everything revert-like (eg, as
Elijah points out) from that command.
Sam.
^ permalink raw reply
* Re: [PATHv3 2/3] gitweb: retrieve snapshot format from PATH_INFO
From: Junio C Hamano @ 2008-11-03 6:17 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jakub Narebski, git, Petr Baudis
In-Reply-To: <1225617699-30004-3-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> + # It's also useless to try any matching unless $refname has a dot,
> + # so we check for that too
> + if ($input_params{'action'} eq 'snapshot' &&
This broke t9500 because $input_params{'action'} can be undef. What I'll
be pushing out on 'pu' has a fixup on it (I am rewinding and rebuilding
'pu' right now so it will be a while).
Next time, please make sure that your patches pass the tests before sending
them out.
Thanks.
^ permalink raw reply
* Re: [PATCH] Document that git-log takes --all-match.
From: Junio C Hamano @ 2008-11-03 6:17 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Git Mailing List
In-Reply-To: <237967ef0811021032j15f7d9cbudfdf9350bc521cd6@mail.gmail.com>
"Mikael Magnusson" <mikachu@gmail.com> writes:
> It's already listed in the bash completion. Feel free to reword.
This is a bad strategy to get your patch accepted except on a rare
occasion when I'm not too lazy nor busy to "feel free". Besides, the
patch is whitespace damaged.
I fixed it up and queued it nevertheless. Thanks.
^ permalink raw reply
* Re: Pull request for sub-tree merge into /contrib/gitstats
From: Johannes Schindelin @ 2008-11-03 6:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sverre, git, dsymonds
In-Reply-To: <bd6139dc0811021124q5ba22d6bm6655f735aaeb379b@mail.gmail.com>
Hi,
On Sun, 2 Nov 2008, Sverre Rabbelier wrote:
> On Thu, Oct 30, 2008 at 20:24, Junio C Hamano <gitster@pobox.com> wrote:
> > I have a mixed feeling about this. From a longer-term perspective, do
> > you really want this to be a part of git.git repository?
>
> My main reason for wanting to have it in git.git is getting additional
> exposure, being in /contrib seems like a good way to do that.
>
> > I do not mind having notes to endorse and advocate "stats" as one of
> > the "Third party packages that may make your git life more
> > pleasuable", just like tig, stgit, guilt and topgit, but I cannot
> > convince myself that merging it as a subtree is the right thing to do
> > at this point.
>
> Heh, blame Johannes for that one; the main reason for not doing
> something like this earlier was my uncertaincy as to -what- to do. Dscho
> suggested to request-pull a subtree merge, which is what I did.
Actually, I suggested that the end result be submitted as a single patch
against contrib/, but dsymonds objected that that would lose all history,
and I concurred that it would be nice to have all changes with the design
decisions recorded as commit messages, too.
Actually, in the meantime, I am of two minds. On the one hand, I would
just like to have the scripts in contrib/ (as a result of one commit), and
on the other hand, I would not like to lose history of gitstats.
So I roll the ball back into your (Junio's) half, albeit gently.
Ciao,
Dscho
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Johannes Schindelin @ 2008-11-03 6:51 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0811021716y37ba999fkc2085b1060fbea2d@mail.gmail.com>
Hi,
On Mon, 3 Nov 2008, Geoff Russell wrote:
> On Thu, Oct 30, 2008 at 1:40 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Wed, 29 Oct 2008, Geoff Russell wrote:
> >
> >> I want to export "the last N days" of a repository to create a copy
> >> which has an origin which is the state of the repository N days ago
> >> and has all the history between then and now.
> >>
> >> Can fast-export do this?
> >
> > Yes. See the --since=... option.
>
> Sorry, I didn't explain what I want very well. N days ago I had a
> working directory in a state S with files F1,F2,F3,... I want to dump
> all the history before then so that this is my new starting point, so I
> want to keep all changes since then.
Well, if you are interested in the history of your _local_ ref, then you
should use reflogs:
$ git log --since=HEAD@{10.days.ago}
Hth,
Dscho
P.S.: man git-reflog
^ permalink raw reply
* Re: Git and Media repositories....
From: Johannes Schindelin @ 2008-11-03 6:56 UTC (permalink / raw)
To: Tim Ansell; +Cc: git
In-Reply-To: <1225655428.11693.10.camel@vaio>
Hi,
On Sun, 2 Nov 2008, Tim Ansell wrote:
> Last week at the gittogether I lead some discussions about how we could
> make Git better support large media repositories (which is one area
> where Subversion still make sense). It was suggested that I post to this
> list to get a discussion going.
>
> The general idea is that we always clone the complete meta-data (tags,
> commits and trees) and then only clone blobs when they are needed (using
> something like alternates). This allows us to support shallow, narrow
> and sparse checkouts while still being able to perform operations such
> as committing and merging.
>
> You can find a copy of the summary presentation at
> http://www.thousandparsec.net/~tim/media+git.pdf
>
> I have started working on adapting git to check a remote http alternate
> to provide a proof of concept.
>
> I appreciate any help or suggestions.
You might find this message (and others from the same time frame and
author) pretty interesting:
http://article.gmane.org/gmane.comp.version-control.git/48485
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-03 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <7v3ai9226q.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 02, 2008 at 02:27:57PM -0800, Junio C Hamano wrote:
> >> + * 'git push --matching' does what 'git push' does today (without
> >> + explicit configuration)
> >
> > I think this is reasonable even without other changes, just to override
> > any configuration.
>
> I don't. Can't you say "git push $there HEAD" these days? I vaguely
> recall that there is a way to configure push that way for people too lazy
> to type "origin HEAD" after "git push".
I think you are reading more into my statement than I intended. I meant
that adding an explicit --matching was reasonable, _even if it matches
the default_. I can think of two reasons:
1. Even if it is a no-op, it is more explicit for showing newbies what
is going on. And it also means that _if_ we wanted to introduce
new behavior or configurability, we will have already had
"--matching" for some time. So it will be safe(r) at that point to
immediately start saying "--matching" in your scripts to specify the
behavior you want, without as much worry about confusing an older
version.
2. Even today, the behavior of push can be modified with configuration
in remote.*.mirror. I would expect "git push --matching" to override
this. Though perhaps that is too confusing a behavior, as mirroring
does more than just ref selection, including force-updating.
So my statement was not anything about "git push $there HEAD", but just
that adding "--matching" was reasonable.
> I think I was neutral in the discussion that led to the removal of
> "git-export", but the rationale IIRC was exactly because "git-export" can
> be done by simply piping "git-tar" to tar. On the other hand, if all you
> had was "export" and you wanted to create a release tar/zip ball, you have
> to first create a (potentially huge) hierarchy in the filesystem only to
> archive it. This change needs to defend that the benefit of being able to
> create a new non-git checkout elsewhere on the filesystem far outweighs
> the downside of addition of another command (i.e. "eek, why does git have
> that many commands" from new people).
I think the complaint is just that it is awkward to have to pipe to tar
(and harder to check error status), when "export to directory" is a
reasonably common request.
If the concern is about another command, then perhaps rather than "git
export" it would be simpler to have "git archive --format=dir" as a
convenience (and it could even use the checkout-index optimization in
the local case, rather than generating a tar).
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-03 6:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081103065636.GB10772@coredump.intra.peff.net>
On Mon, Nov 03, 2008 at 01:56:36AM -0500, Jeff King wrote:
> So my statement was not anything about "git push $there HEAD", but just
> that adding "--matching" was reasonable.
And btw, I am not saying I necessarily disagree with Sam's proposal
about bare "git push". I am undecided about the best course of action
there.
I just wanted to make clear that it was not what I was talking about in
the original mail.
-Peff
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-03 7:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, David Symonds, git, Stephan Beyer
In-Reply-To: <7vprle1qdl.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 02, 2008 at 01:30:46AM -0700, Junio C Hamano wrote:
> A flag "--staged" that means "staged changes and changes in the work tree"
> is no worse than the current "--index". If we were to shoot for clarity,
Well, there is another flag state to be considered, of course, which is
"no flag". So I think "--staged" is fine to mean the working tree and
staged, as long as the default (i.e., no option given) is to operate on
the working tree.
I can't think offhand of any commands that violate that assumption.
> how about --staged-only (aka --cached) vs --staged-and-unstaged (aka --index)?
>
> I am actually actively unhappy about the latter, but I like more
> descriptive --staged-only for the former a lot better.
Agreed. --staged-only is fine to me, but --staged-and-unstaged just
seems too long.
-Peff
^ permalink raw reply
* Re: Pull request for sub-tree merge into /contrib/gitstats
From: David Symonds @ 2008-11-03 7:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, sverre, git
In-Reply-To: <alpine.DEB.1.00.0811030729071.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Sun, Nov 2, 2008 at 11:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Actually, I suggested that the end result be submitted as a single patch
> against contrib/, but dsymonds objected that that would lose all history,
> and I concurred that it would be nice to have all changes with the design
> decisions recorded as commit messages, too.
I chatted to Sverre separately, and I think we concluded that we could
probably just do a single patch (no history, no changelogs, etc.), and
just point to the complete git-stats.git repo for folk who want the
detail.
Dave.
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-03 7:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Björn Steinbrink, Johannes Schindelin, David Symonds, git,
Stephan Beyer
In-Reply-To: <7vljw2yo93.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 02, 2008 at 10:30:16AM -0800, Junio C Hamano wrote:
> > Looking at --cached/--index we have basically three things:
> >
> > --cached to refer to the state of the index (diff, grep, [stash], ...)
> > --cached to _work on_ the index only (rm, apply, ...)
> > --index to _work on_ both the index and the working tree (apply, ...)
>
> I think the earlier two are the same thing. The only difference between
> them is that in the first one, the definition of your "work on" happens to
> be a read-only operation. Am I mistaken?
I think that is somewhat the case for "grep", for example. But the
confusion is that diff is really a different beast, because you are
comparing two _different_ locations.
So "git diff --staged", while it makes sense to us (since we are asking
"what is staged"), is not consistent with the discussed rules. In
particular:
1. It operates on just the "stage" and not the working tree, so it
should be "--staged-only". But the only there is nonsensical.
2. The default is _already_ operating on the staging area, so you are
really switching up the working tree for the HEAD in what you are
diffing. So in that sense, it doesn't convey the change in
operation very well.
And I am not proposing a change here (except to perhaps "git diff
--staged" instead of "--cached"). Just pointing out that it does not
follow the "--staged operates on both, --staged-only operates on just
the index" rule.
Hrm. For that matter, grep is a bit different, too. Since I would expect
"git grep --staged" to find only staged things, not things in both the
working tree and the index. So perhaps there is a difference between
commands that modify and commands that inspect.
-Peff
^ permalink raw reply
* Re: Pull request for sub-tree merge into /contrib/gitstats
From: Sverre Rabbelier @ 2008-11-03 8:40 UTC (permalink / raw)
To: David Symonds; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <ee77f5c20811022307r59dc4d09m20551a339a2993ea@mail.gmail.com>
On Mon, Nov 3, 2008 at 08:07, David Symonds <dsymonds@gmail.com> wrote:
> I chatted to Sverre separately, and I think we concluded that we could
> probably just do a single patch (no history, no changelogs, etc.), and
> just point to the complete git-stats.git repo for folk who want the
> detail.
Either is fine with me, anything to get more exposure is fine with me :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-11-03 8:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Nicolas Pitre
In-Reply-To: <200810310836.02908.jnareb@gmail.com>
On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote:
> > > git checkout --track origin/wr34251-do-something
> >
> > Ah, that's a new feature. Still, I think it's poorly Huffman coded; far
> > too verbose.
>
> Well, either you have a little bit more verbose, or you have to have
> some DWIM-mery, which (as usual with DWIM) can go wrong.
That's right, you need to choose when to assume that the user meant
something that they didn't write very carefully.
But look at this:
git checkout origin/master
git checkout -t origin/master
The option is called "--track", yet in this case what it actually means
in the default situation where you have autosetupmerge (or whatever it's
really called) set to true, is that it modifies the command to imply "-b
master". So, in this situation, that is clearly what was meant.
Perhaps you can give an example of why this particular piece of DWIM
might not be WYM?
Sam.
^ permalink raw reply
* Re: error: non-monotonic index
From: Pierre Habouzit @ 2008-11-03 8:51 UTC (permalink / raw)
To: Peter Teoh; +Cc: git
In-Reply-To: <804dabb00811021832k28276bf7ke0146a8bbd648574@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
On Mon, Nov 03, 2008 at 02:32:44AM +0000, Peter Teoh wrote:
> I git pull and got errors, then git repack and pull again......the
> error increased....what happened?
what is your local git version and the remote one ?
It's likely that your local git is not aware of packs v2 which is now
default. You want to upgrade your local git, if you're on Debian etch,
updates have been pushed in the last dot release. Or you can even use
git-core from backports.org which is even more up to date (1.6.sth I
guess).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: make the message file name more specific.
From: Pierre Habouzit @ 2008-11-03 8:53 UTC (permalink / raw)
To: Ian Hilt; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0811021629110.25369@sys-0.hiltweb.site>
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
On Sun, Nov 02, 2008 at 09:34:53PM +0000, Ian Hilt wrote:
> On Sun, 2 Nov 2008, Pierre Habouzit wrote:
> > On Sun, Nov 02, 2008 at 06:18:08AM +0000, Junio C Hamano wrote:
> > > Having said that, if we were to do this, let's do it the right way and put
> > > these "temporary" files under $GIT_DIR.
> >
> > Agreed, I should have done that.
>
> Perhaps like this:
>
> my $compose_filename = $repo->repo_path() . "/sendemail.msg.$$";
>
> where $repo is a repository instance.
$repo is a repository instance, I'm waiting for all the comments to fade
up to take them into account and resend a proper series.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: .gitattributes glob matching broken
From: Jeff King @ 2008-11-03 9:09 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83od0yaxzk.fsf@kalahari.s2.org>
On Sun, Nov 02, 2008 at 06:33:51PM +0200, Hannu Koivisto wrote:
> It seems that, for example, glob pattern *.s matches files with .sh
> extension at least with checkout and reset --hard but git status
> thinks otherwise:
I think your analysis is incorrect. I will try to explain what is
happening.
> mkdir test
> cd test
> git init
> echo -e "*.sh -crlf\n*.s crlf" > .gitattributes
> echo -e "foobar\nfoobar\nfoobar" > kala.s
> echo -e "foobar\nfoobar\nfoobar" > kala.sh
> git add .gitattributes kala.s kala.sh
> git commit -m "Foo."
OK, so here we have two files, one of which we are telling git is text
and one of which we are telling git is not text. Since we don't have
autocrlf set at all, of course nothing happens here.
> git clone -n test test2
And here we clone without checking out, so there are no files yet.
> cd test2
> git config core.autocrlf true
> git checkout
And now we do check out the files, with autocrlf applied. But what are
we left with? When I run this, _both_ files were detected as text and
have CRLF line endings. So here I think is where git didn't do what you
expected: kala.sh should not have had CRLF conversion applied.
This is a known limitation of the attributes mechanism: it only reads
from .gitattributes in the filesystem (or from .git/info/attributes),
and not from the tree that is being checked out. This is something that
should be addressed, but nobody has stepped up with a patch yet (though
there has been some preliminary discussion).
> git status
>
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working
> # directory)
> #
> # modified: kala.sh
> #
> no changes added to commit (use "git add" and/or "git commit -a")
So yes, this status makes perfect sense, then. The file "kala.sh" has
CRLFs in the filesystem, but we have told git that it is not a file
which gets converted. So it looks like those CRs have been added.
The problem, again, is that we have inconsistently applied the
gitattributes. They were _not_ applied during checkout (because
.gitattributes did not exist yet), but they _are_ being applied here.
To "fix" this, you can then do a "git reset --hard" which will respect
your .gitattributes (since it is now checked out). And further file
creation and checkout should work OK.
-Peff
^ permalink raw reply
* Re: [PATCH] git send-email: allow any rev-list option as an argument.
From: Pierre Habouzit @ 2008-11-03 9:15 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081102180220.GA5726@sigio.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 3769 bytes --]
On Sun, Nov 02, 2008 at 06:02:21PM +0000, Jeff King wrote:
> On Sun, Nov 02, 2008 at 10:39:07AM +0100, Pierre Habouzit wrote:
>
> > Well it still messes the file/reference name conflict with no way to
> > prevent it because of the backward compatibility, and even if unlikely
> > it's still possible.
>
> Hmm. As Junio mentioned, this is really an easier way of doing:
>
> git format-patch -o tmp "$@"
> $EDITOR tmp/*
> git send-email tmp
>
> So I guess a wrapper program would suffice, that just called send-email.
> But of course then you would have to think of a new name, and explain
> the confusion between it and send-email.
Well that defeats the purpose of fixing send-email to me. I really would
like to see this fixed properly like it should. I mean it makes sense to
me to use _three_ commands where one should be enough. Not to mention
that introducing a new command is just completely against the spirit of
*simplifying* the current UI ;)
Actually I see a few possibilities.
(1) The first one is to pass a --[no]-format-patch flag to
git-send-email which says that it should understand arguments as
format-patch arguments. You add to that a sendemail.format-patch
setting that would default to false for backward compatibility sake,
that would allow the user to force --format-patch as a default.
This would e.g. cleanly allow: git send-email --format-patch -3 HEAD.
I would understand if people dislike the setting: it basically
modifies the behaviour of a git command a lot, which has been
frowned upon in the past. Even though I would argue than using
git-send-email in scripting is quite bad, for something that you can
probably replace with:
while read patchname; do mail some@where.org < $patchname; done < git format-patch "$@"
But if people think it's too dangerous, replacing it with a short
switch so that it's not too painful to use would fly for me,
something like -F or whatever.
(2) Another way is to add a --pass-to-format-patch kind of option that
would take its arguments and pass it to git-format-patch. Like in:
git send-email --pass-to-format-patch "-3 HEAD". (Of course a short
switch would help ;p).
(3) Use -- for mandatory separating <format-patch> arguments like this:
git send-email [send-email options] -- -3 HEAD
or if you want to send patches that would modify only a given path:
git send-email [s-e options] -- origin/next.. -- git-gui
that would run internally:
git format-patch origin/next.. -- git-gui
I would say that I dislike (2) a LOT because it's a pain to use: needs a
lot of quoting, and it gets worse if you want to pass things with spaces
in it to format-patch.
(2) has the small drawback of not being 100% backward compatible: with
the current use of perl Getoptions, -- is used to stop options
processing, and people _may_ have used it to do `git s-e -- --my.patch`
and such a use would break. However this is highly unlikely to cause
issues in real life I think (unlike the problem of refs against filename
clashes).
In (1) people may dislike the idea of a setting, I've not strong
feelings about it, I won't mind if it gets rejected, a short switch will
do just fine then.
As a summary, I'd say that I like both (1) and (3) because those are
handy, short, and either completely or mostly backward compatible. My
way would be to go down (1) and add a alias.s-e = !git send-email -F in
my .gitconfig.
What do you think ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-11-03 9:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <7v3ai9226q.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
On Sun, Nov 02, 2008 at 10:27:57PM +0000, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> + * 'git push --matching' does what 'git push' does today (without
> >> + explicit configuration)
> >
> > I think this is reasonable even without other changes, just to override
> > any configuration.
>
> I don't. Can't you say "git push $there HEAD" these days? I vaguely
> recall that there is a way to configure push that way for people too lazy
> to type "origin HEAD" after "git push".
Yes, but it's broken in the sense that if you're in a non matching
branch it creates it remotely. The way to configure it is to say
remote.push = HEAD in your .gitconfig or sth similar. I removed it
because I've created 2 times a new branch remotely that I didn't want to
because I was tired and forgot to checkout and merge into the proper
one.
I rarely do mistakes with git, but something like more than half of my
mistakes are with push. I've argued that in the past, I know most of the
other core git developers disagree with the fact that git-push UI is not
helping users to not shoot themselves in the foot, I disagree, but there
is not much I can do if I'm 1:10 to think that ;)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Pierre Habouzit @ 2008-11-03 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, pasky, srabbelier
In-Reply-To: <7viqr5wgl7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]
On Mon, Nov 03, 2008 at 04:58:44AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > +case "$prune_empty,$filter_commit" in
> > +',')
> > + filter_commit='git commit-tree "$@"';;
> > +'t,')
> > + filter_commit="$functions;"' git_commit_non_empty_tree "$@"';;
> > +','*)
> > + ;;
> > +*)
> > + die "Cannot set --prune-empty and --filter-commit at the same time"
> > +esac
>
> This is only style issue, but I find the above extremely difficult to
> read. If it were either:
>
> case ... in
> ,) do "neither set case" ;;
> t,) do "prune but not filter case" ;;
> *) do "both set case" ;;
> esac
>
> or (rather amateurish but conveys what it wants to do more clearly):
>
> case ... in
> '','') do "neither set case" ;;
> t,'') do "prune but not filter case" ;;
> t,t) do "both set case" ;;
> esac
>
> I wouldn't have to wonder which sq pairs with which one.
agreed.
> > diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
> > index b0a9d7d..352b56b 100755
> > --- a/t/t7003-filter-branch.sh
> > +++ b/t/t7003-filter-branch.sh
> > @@ -262,4 +262,12 @@ test_expect_success 'Tag name filtering allows slashes in tag names' '
> > test_cmp expect actual
> > '
> >
> > +test_expect_success 'Prune empty commits' '
> > + make_commit to_remove &&
> > + (git rev-list HEAD | grep -v $(git rev-parse HEAD)) > expect &&
>
> I am not sure what this one is doing.
>
> - Isn't this the same as "git rev-list HEAD^"?
> - Do you need a subshell?
The filter-branch is supposed to prune the last commit done (current
HEAD) from the revision list. So I build the rev-list we're supposed to
have in the end, and remove the matching ref from it. I don't see how to
avoid the subshell though, but if someone knows better please do :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] git-cvsimport.perl: use human readable names for option values
From: Francis Galiegue @ 2008-11-03 9:31 UTC (permalink / raw)
To: git
Hello,
As I am keen to make my company use git eventually, but they have a really,
really messy CVS tree that git-cvs*.perl cannot handle right now, I've
decided to have a serious look at the code.
But if others want to have a look at the code, I think it should be made a
little more readable first, hence this patch.
Comments? In particular, I'm thinking about the option names, maybe some are
not in sync with what git internal really are.
---
git-cvsimport.perl: use human readable names for option values
It has reclaimed to rewrite the read_repo_config() function as well, but the
good thing is that "no strcit 'refs'" is gone too.
---
git-cvsimport.perl | 244
++++++++++++++++++++++++++++++++--------------------
1 files changed, 150 insertions(+), 94 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e439202..b9a552f 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -29,7 +29,51 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,
$opt_P, $opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r);
+#
+# Option values
+#
+my $help = undef; # -h
+my $branch_for_head = undef; # -o
+my $verbose = undef; # -v
+my $cvs_kill_keywords = undef; # -k
+my $convert_underscores = undef; # -u
+my $cvsroot = undef; # -d
+my $cvsps_options = undef; # -p
+my $git_repos_root = undef; # -C
+my $cvsps_fuzz = undef; # -z
+my $import_only = undef; # -i
+my $cvsps_output_file = undef; # -P
+my $branch_subst = undef, # -s
+my $detect_merges = undef; # -m
+my @more_merge_regexes = (); # -M
+my $author_conv_file = undef; # -A
+my $skip_paths = undef; # -S
+my $commit_limits = undef; # -L
+my $all_commits = undef; # -a
+my $remote_path = undef; # -r
+
+my %options = (
+ "h" => \$help,
+ "o=s" => \$branch_for_head,
+ "v" => \$verbose,
+ "k" => \$cvs_kill_keywords,
+ "u" => \$convert_underscores,
+ "d=s" => \$cvsroot,
+ "p=s" => \$cvsps_options,
+ "C=s" => \$git_repos_root,
+ "z=s" => \$cvsps_fuzz,
+ "i" => \$import_only,
+ "P=s" => \$cvsps_output_file,
+ "s=s" => \$branch_subst,
+ "m" => \$detect_merges,
+ "M=s" => \@more_merge_regexes,
+ "A=s" => \$author_conv_file,
+ "S=s" => \$skip_paths,
+ "L=s" => \$commit_limits,
+ "a" => \$all_commits,
+ "r=s" => \$remote_path
+);
+
my (%conv_author_name, %conv_author_email);
sub usage(;$) {
@@ -88,37 +132,48 @@ sub write_author_info($) {
close ($f);
}
-# convert getopts specs for use by git config
-sub read_repo_config {
- # Split the string between characters, unless there is a ':'
- # So "abc:de" becomes ["a", "b", "c:", "d", "e"]
- my @opts = split(/ *(?!:)/, shift);
- foreach my $o (@opts) {
- my $key = $o;
- $key =~ s/://g;
- my $arg = 'git config';
- $arg .= ' --bool' if ($o !~ /:$/);
-
- chomp(my $tmp = `$arg --get cvsimport.$key`);
- if ($tmp && !($arg =~ /--bool/ && $tmp eq 'false')) {
- no strict 'refs';
- my $opt_name = "opt_" . $key;
- if (!$$opt_name) {
- $$opt_name = $tmp;
- }
+sub read_repo_config ()
+{
+ my @option_keys = keys %options;
+
+ while (my ($opt, $ref) = each %options) {
+ my $key = $opt;
+ my $is_boolean = 0;
+ my $cmd = "git config";
+ unless ($key =~ s/=s$//) {
+ $is_boolean = 1;
+ $cmd .= " --bool";
+ }
+ $cmd .= " cvsimport.$key";
+
+ chomp(my $tmp = qx/$cmd/);
+ $tmp or next;
+
+ if (ref($ref) eq "ARRAY") {
+ #
+ # FIXME: unhandled...
+ # However this could be handled by splitting $tmp with
+ # /\s*,\s*/ and pusing the result into @$ref (for the -M
+ # option)
+ #
+ next;
+ }
+
+ if ($is_boolean) {
+ $$ref = ("$tmp" eq "true") ? 1 : 0;
+ } else {
+ $$ref = "$tmp";
}
}
}
-my $opts = "haivmkuo:d:p:r:C:z:s:M:P:A:S:L:";
-read_repo_config($opts);
+
+read_repo_config();
Getopt::Long::Configure( 'no_ignore_case', 'bundling' );
-# turn the Getopt::Std specification in a Getopt::Long one,
-# with support for multiple -M options
-GetOptions( map { s/:/=s/; /M/ ? "$_\@" : $_ } split( /(?!:)/, $opts ) )
- or usage();
-usage if $opt_h;
+GetOptions(%options) or usage();
+
+usage() if $help;
if (@ARGV == 0) {
chomp(my $module = `git config --get cvsimport.module`);
@@ -126,31 +181,32 @@ if (@ARGV == 0) {
}
@ARGV <= 1 or usage("You can't specify more than one CVS module");
-if ($opt_d) {
- $ENV{"CVSROOT"} = $opt_d;
+if ($cvsroot) {
+ $ENV{"CVSROOT"} = $cvsroot;
} elsif (-f 'CVS/Root') {
open my $f, '<', 'CVS/Root' or die 'Failed to open CVS/Root';
- $opt_d = <$f>;
- chomp $opt_d;
+ $cvsroot = <$f>;
+ chomp $cvsroot;
close $f;
- $ENV{"CVSROOT"} = $opt_d;
+ $ENV{"CVSROOT"} = $cvsroot;
} elsif ($ENV{"CVSROOT"}) {
- $opt_d = $ENV{"CVSROOT"};
+ $cvsroot = $ENV{"CVSROOT"};
} else {
usage("CVSROOT needs to be set");
}
-$opt_s ||= "-";
-$opt_a ||= 0;
+$branch_subst ||= "-";
+$all_commits ||= 0;
-my $git_tree = $opt_C;
+my $git_tree = $git_repos_root;
$git_tree ||= ".";
my $remote;
-if (defined $opt_r) {
- $remote = 'refs/remotes/' . $opt_r;
- $opt_o ||= "master";
+
+if (defined $remote_path) {
+ $remote = 'refs/remotes/' . $remote_path;
+ $branch_for_head ||= "master";
} else {
- $opt_o ||= "origin";
+ $branch_for_head ||= "origin";
$remote = 'refs/heads';
}
@@ -168,11 +224,11 @@ if ($#ARGV == 0) {
}
our @mergerx = ();
-if ($opt_m) {
+if ($detect_merges) {
@mergerx = ( qr/\b(?:from|of|merge|merging|merged) ([-\w]+)/i );
}
-if (@opt_M) {
- push (@mergerx, map { qr/$_/ } @opt_M);
+if (@more_merge_regexes) {
+ push (@mergerx, map { qr/$_/ } @more_merge_regexes);
}
# Remember UTC of our starting time
@@ -370,7 +426,7 @@ sub _file {
$self->{'socketo'}->write("Argument -N\n") or return undef;
$self->{'socketo'}->write("Argument -P\n") or return undef;
# -kk: Linus' version doesn't use it - defaults to off
- if ($opt_k) {
+ if ($cvs_kill_keywords) {
$self->{'socketo'}->write("Argument -kk\n") or return undef;
}
$self->{'socketo'}->write("Argument -r\n") or return undef;
@@ -487,7 +543,7 @@ sub _fetchfile {
package main;
-my $cvs = CVSconn->new($opt_d, $cvs_tree);
+my $cvs = CVSconn->new($cvsroot, $cvs_tree);
sub pdate($) {
@@ -565,7 +621,7 @@ unless (-d $git_dir) {
system("git-read-tree");
die "Cannot init an empty tree: $?\n" if $?;
- $last_branch = $opt_o;
+ $last_branch = $branch_for_head;
$orig_branch = "";
} else {
open(F, "git-symbolic-ref HEAD |") or
@@ -592,8 +648,8 @@ unless (-d $git_dir) {
$branch_date{$head} = $1;
}
close(H);
- if (!exists $branch_date{$opt_o}) {
- die "Branch '$opt_o' does not exist.\n".
+ if (!exists $branch_date{$branch_for_head}) {
+ die "Branch '$branch_for_head' does not exist.\n".
"Either use the correct '-o branch' option,\n".
"or import to a new repository.\n";
}
@@ -605,31 +661,31 @@ unless (-d $git_dir) {
# now we read (and possibly save) author-info as well
-f "$git_dir/cvs-authors" and
read_author_info("$git_dir/cvs-authors");
-if ($opt_A) {
- read_author_info($opt_A);
+if ($author_conv_file) {
+ read_author_info($author_conv_file);
write_author_info("$git_dir/cvs-authors");
}
#
# run cvsps into a file unless we are getting
-# it passed as a file via $opt_P
+# it passed as a file via $cvsps_output_file
#
my $cvspsfile;
-unless ($opt_P) {
- print "Running cvsps...\n" if $opt_v;
+unless ($cvsps_output_file) {
+ print "Running cvsps...\n" if $verbose;
my $pid = open(CVSPS,"-|");
my $cvspsfh;
die "Cannot fork: $!\n" unless defined $pid;
unless ($pid) {
my @opt;
- @opt = split(/,/,$opt_p) if defined $opt_p;
- unshift @opt, '-z', $opt_z if defined $opt_z;
- unshift @opt, '-q' unless defined $opt_v;
- unless (defined($opt_p) && $opt_p =~ m/--no-cvs-direct/) {
+ @opt = split(/,/,$cvsps_options) if defined $cvsps_options;
+ unshift @opt, '-z', $cvsps_fuzz if defined $cvsps_fuzz;
+ unshift @opt, '-q' unless defined $verbose;
+ unless (defined($cvsps_options) && $cvsps_options =~ m/--no-cvs-direct/) {
push @opt, '--cvs-direct';
}
- exec("cvsps","--norc",@opt,"-u","-A",'--root',$opt_d,$cvs_tree);
+ exec("cvsps","--norc",@opt,"-u","-A",'--root',$cvsroot,$cvs_tree);
die "Could not start cvsps: $!\n";
}
($cvspsfh, $cvspsfile) = tempfile('gitXXXXXX', SUFFIX => '.cvsps',
@@ -641,7 +697,7 @@ unless ($opt_P) {
$? == 0 or die "git-cvsimport: fatal: cvsps reported error\n";
close $cvspsfh;
} else {
- $cvspsfile = $opt_P;
+ $cvspsfile = $cvsps_output_file;
}
open(CVS, "<$cvspsfile") or die $!;
@@ -688,7 +744,7 @@ sub write_tree () {
or die "Cannot get tree id ($tree): $!";
close($fh)
or die "Error running git-write-tree: $?\n";
- print "Tree ID $tree\n" if $opt_v;
+ print "Tree ID $tree\n" if $verbose;
return $tree;
}
@@ -699,7 +755,7 @@ my (@old,@new,@skipped,%ignorebranch);
$ignorebranch{'#CVSPS_NO_BRANCH'} = 1;
sub commit {
- if ($branch eq $opt_o && !$index{branch} &&
+ if ($branch eq $branch_for_head && !$index{branch} &&
!get_headref("$remote/$branch")) {
# looks like an initial commit
# use the index primed by git-init
@@ -725,7 +781,7 @@ sub commit {
@old = @new = ();
my $tree = write_tree();
my $parent = get_headref("$remote/$last_branch");
- print "Parent ID " . ($parent ? $parent : "(empty)") . "\n" if $opt_v;
+ print "Parent ID " . ($parent ? $parent : "(empty)") . "\n" if $verbose;
my @commit_args;
push @commit_args, ("-p", $parent) if $parent;
@@ -734,10 +790,10 @@ sub commit {
# based on the commit msg
foreach my $rx (@mergerx) {
next unless $logmsg =~ $rx && $1;
- my $mparent = $1 eq 'HEAD' ? $opt_o : $1;
+ my $mparent = $1 eq 'HEAD' ? $branch_for_head : $1;
if (my $sha1 = get_headref("$remote/$mparent")) {
push @commit_args, '-p', "$remote/$mparent";
- print "Merge parent branch: $mparent\n" if $opt_v;
+ print "Merge parent branch: $mparent\n" if $verbose;
}
}
@@ -764,10 +820,10 @@ sub commit {
print($commit_write "$logmsg\n") && close($commit_write)
or die "Error writing to git-commit-tree: $!\n";
- print "Committed patch $patchset ($branch $commit_date)\n" if $opt_v;
+ print "Committed patch $patchset ($branch $commit_date)\n" if $verbose;
chomp(my $cid = <$commit_read>);
is_sha1($cid) or die "Cannot get commit id ($cid): $!\n";
- print "Commit ID $cid\n" if $opt_v;
+ print "Commit ID $cid\n" if $verbose;
close($commit_read);
waitpid($pid,0);
@@ -779,14 +835,14 @@ sub commit {
if ($tag) {
my ($xtag) = $tag;
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
- $xtag =~ tr/_/\./ if ( $opt_u );
- $xtag =~ s/[\/]/$opt_s/g;
+ $xtag =~ tr/_/\./ if ( $convert_underscores );
+ $xtag =~ s/[\/]/$branch_subst/g;
$xtag =~ s/\[//g;
system('git-tag', '-f', $xtag, $cid) == 0
or die "Cannot create tag $xtag: $!\n";
- print "Created tag '$xtag' on '$branch'\n" if $opt_v;
+ print "Created tag '$xtag' on '$branch'\n" if $verbose;
}
};
@@ -822,14 +878,14 @@ while (<CVS>) {
$state = 4;
} elsif ($state == 4 and s/^Branch:\s+//) {
s/\s+$//;
- tr/_/\./ if ( $opt_u );
- s/[\/]/$opt_s/g;
+ tr/_/\./ if ( $convert_underscores );
+ s/[\/]/$branch_subst/g;
$branch = $_;
$state = 5;
} elsif ($state == 5 and s/^Ancestor branch:\s+//) {
s/\s+$//;
$ancestor = $_;
- $ancestor = $opt_o if $ancestor eq "HEAD";
+ $ancestor = $branch_for_head if $ancestor eq "HEAD";
$state = 6;
} elsif ($state == 5) {
$ancestor = undef;
@@ -847,19 +903,19 @@ while (<CVS>) {
$logmsg = "";
$state = 8;
} elsif ($state == 8 and /^Members:/) {
- $branch = $opt_o if $branch eq "HEAD";
+ $branch = $branch_for_head if $branch eq "HEAD";
if (defined $branch_date{$branch} and $branch_date{$branch} >= $date) {
# skip
- print "skip patchset $patchset: $date before $branch_date{$branch}\n" if
$opt_v;
+ print "skip patchset $patchset: $date before $branch_date{$branch}\n" if
$verbose;
$state = 11;
next;
}
- if (!$opt_a && $starttime - 300 - (defined $opt_z ? $opt_z : 300) <= $date)
{
+ if (!$all_commits && $starttime - 300 - (defined $cvsps_fuzz ?
$cvsps_fuzz : 300) <= $date) {
# skip if the commit is too recent
# given that the cvsps default fuzz is 300s, we give ourselves another
# 300s just in case -- this also prevents skipping commits
# due to server clock drift
- print "skip patchset $patchset: $date too recent\n" if $opt_v;
+ print "skip patchset $patchset: $date too recent\n" if $verbose;
$state = 11;
next;
}
@@ -870,8 +926,8 @@ while (<CVS>) {
}
if ($ancestor) {
if ($ancestor eq $branch) {
- print STDERR "Branch $branch erroneously stems from itself -- changed
ancestor to $opt_o\n";
- $ancestor = $opt_o;
+ print STDERR "Branch $branch erroneously stems from itself -- changed
ancestor to $branch_for_head\n";
+ $ancestor = $branch_for_head;
}
if (defined get_headref("$remote/$branch")) {
print STDERR "Branch $branch already exists!\n";
@@ -905,18 +961,18 @@ while (<CVS>) {
my $fn = $1;
my $rev = $3;
$fn =~ s#^/+##;
- if ($opt_S && $fn =~ m/$opt_S/) {
+ if ($skip_paths && $fn =~ m/$skip_paths/) {
print "SKIPPING $fn v $rev\n";
push(@skipped, $fn);
next;
}
- print "Fetching $fn v $rev\n" if $opt_v;
+ print "Fetching $fn v $rev\n" if $verbose;
my ($tmpname, $size) = $cvs->file($fn,$rev);
if ($size == -1) {
push(@old,$fn);
- print "Drop $fn\n" if $opt_v;
+ print "Drop $fn\n" if $verbose;
} else {
- print "".($init ? "New" : "Update")." $fn: $size bytes\n" if $opt_v;
+ print "".($init ? "New" : "Update")." $fn: $size bytes\n" if $verbose;
my $pid = open(my $F, '-|');
die $! unless defined $pid;
if (!$pid) {
@@ -934,12 +990,12 @@ while (<CVS>) {
my $fn = $1;
$fn =~ s#^/+##;
push(@old,$fn);
- print "Delete $fn\n" if $opt_v;
+ print "Delete $fn\n" if $verbose;
} elsif ($state == 9 and /^\s*$/) {
$state = 10;
} elsif (($state == 9 or $state == 10) and /^-+$/) {
$commitcount++;
- if ($opt_L && $commitcount > $opt_L) {
+ if ($commit_limits && $commitcount > $commit_limits) {
last;
}
commit();
@@ -957,7 +1013,7 @@ while (<CVS>) {
}
commit() if $branch and $state != 11;
-unless ($opt_P) {
+unless ($cvsps_output_file) {
unlink($cvspsfile);
}
@@ -985,31 +1041,31 @@ if (defined $orig_git_index) {
# Now switch back to the branch we were in before all of this happened
if ($orig_branch) {
- print "DONE.\n" if $opt_v;
- if ($opt_i) {
+ print "DONE.\n" if $verbose;
+ if ($import_only) {
exit 0;
}
my $tip_at_end = `git-rev-parse --verify HEAD`;
if ($tip_at_start ne $tip_at_end) {
for ($tip_at_start, $tip_at_end) { chomp; }
- print "Fetched into the current branch.\n" if $opt_v;
+ print "Fetched into the current branch.\n" if $verbose;
system(qw(git-read-tree -u -m),
$tip_at_start, $tip_at_end);
die "Fast-forward update failed: $?\n" if $?;
}
else {
- system(qw(git-merge cvsimport HEAD), "$remote/$opt_o");
- die "Could not merge $opt_o into the current branch.\n" if $?;
+ system(qw(git-merge cvsimport HEAD), "$remote/$branch_for_head");
+ die "Could not merge $branch_for_head into the current branch.\n" if $?;
}
} else {
$orig_branch = "master";
- print "DONE; creating $orig_branch branch\n" if $opt_v;
- system("git-update-ref", "refs/heads/master", "$remote/$opt_o")
+ print "DONE; creating $orig_branch branch\n" if $verbose;
+ system("git-update-ref", "refs/heads/master", "$remote/$branch_for_head")
unless defined get_headref('refs/heads/master');
- system("git-symbolic-ref", "$remote/HEAD", "$remote/$opt_o")
- if ($opt_r && $opt_o ne 'HEAD');
+ system("git-symbolic-ref", "$remote/HEAD", "$remote/$branch_for_head")
+ if ($remote_path && $branch_for_head ne 'HEAD');
system('git-update-ref', 'HEAD', "$orig_branch");
- unless ($opt_i) {
+ unless ($import_only) {
system('git checkout -f');
die "checkout failed: $?\n" if $?;
}
--
fge
^ permalink raw reply related
* How to send patch series without storing them to disk?
From: Liu Yubao @ 2008-11-03 9:33 UTC (permalink / raw)
To: git
Hi,
I want to send patches like this:
git format-patch --stdout --no-color -C --thread -n $oldrev..$newrev | ...send...
It seems git-send-email can't read email from stdin.
I tried to send one patch using git-send-email, it reported "Syntax: AUTH mechanism".
git send-email --from <myemail> --to <my-another-email> \
--smtp-pass <mypass> --smtp-user <myaccount> \
--smtp-server <the-smtp-server> \
--smtp-encryption auth \
0001-just-a-test.patch
The parameters about smtp are right, I tested with msmtp. What's wrong?
I have MIME::Base64 and Authen::SASL installed and the smtp server doesn't use
ssl and tls.
^ permalink raw reply
* Re: Git and Media repositories....
From: Jakub Narebski @ 2008-11-03 9:40 UTC (permalink / raw)
To: Tim Ansell; +Cc: git, Dana How
In-Reply-To: <1225655428.11693.10.camel@vaio>
Tim Ansell <mithro@mithis.com> writes:
> Last week at the GitTogether I lead some discussions about how we could
> make Git better support large media repositories (which is one area
> where Subversion still make sense). It was suggested that I post to this
> list to get a discussion going.
>
> The general idea is that we always clone the complete meta-data (tags,
> commits and trees) and then only clone blobs when they are needed (using
> something like alternates). This allows us to support shallow, narrow
> and sparse checkouts while still being able to perform operations such
> as committing and merging.
>
> You can find a copy of the summary presentation at
> http://www.thousandparsec.net/~tim/media+git.pdf
>
> I have started working on adapting git to check a remote http alternate
> to provide a proof of concept.
>
> I appreciate any help or suggestions.
Dana How (CC-ed) worked on better support for large files, but in
corporate setting. The solution that was the result of all discussion
and all patches (not all accpeted) was to create kept packfile for
those large files, and share those packfiles (perhaps via alternates)
using network filesystem, instead of keeping separate copies and
trasferring them on fetch / push.
>From what I remember there was one serious attempt (by serious I mean
here with patches) to add 'lazy clone' / 'sparse clone' / 'remote
alternates', using some kind of "stub" objects and trasferring objects
lazily. This patch was fairly intrusive, and didn't get accepted.
I think you can find it in archives. Unfortunately I haven't bookmarked
this thread...
The problem with lazy clone is that git assumes in many places that if
it has some object, it has all its dependencies. Lazy clone
(on-demand object loading) breaks this assumption... although in your
case (only blobs of large size can be asked to be loaded lazily) it is
migitated somehow.
I also think that you would have to have 'sparse checkout' support.
If you don't have blob in object repository (and don't want to have it
there), you can not check it out. Fortunately this feature is quite
alive, and worked on by Duy (pclouds), see "What's cooking..."
(nd/narrow branch in 'pu').
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Make Pthread link flags configurable
From: Jakub Narebski @ 2008-11-03 9:44 UTC (permalink / raw)
To: David M. Syzdek; +Cc: git
In-Reply-To: <1225669400-79505-1-git-send-email-david.syzdek@acsalaska.net>
david.syzdek@acsalaska.net writes:
> From: David M. Syzdek <david.syzdek@acsalaska.net>
>
> FreeBSD 4.x systems use the linker flags `-pthread' instead of the
> linker flags `-lpthread' when linking against the pthread library.
>
> Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
> ---
> Makefile | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
Would it be possible to add support for this also to configure.ac
(and config.mak.in)?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jakub Narebski @ 2008-11-03 9:48 UTC (permalink / raw)
To: git
In-Reply-To: <1225691960.20883.41.camel@maia.lan>
Sam Vilain wrote:
> On Sun, 2008-11-02 at 14:27 -0800, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>>> + * 'git push --matching' does what 'git push' does today (without
>>>> + explicit configuration)
>>>
>>> I think this is reasonable even without other changes, just to override
>>> any configuration.
>>
>> I don't. Can't you say "git push $there HEAD" these days? I vaguely
>> recall that there is a way to configure push that way for people too lazy
>> to type "origin HEAD" after "git push".
>
> I don't think it's about laziness, it's more about making sure that
> without specifying behaviour, the action of the command is conservative.
> Pushing all matching refs is not conservative; it's "magic". And in my
> experience, people get bitten by it, because they think, "ok, time to
> push this branch", type "git push" and then a lot more than they
> expected gets pushed.
>
> I can see that some people want this behaviour by default; but to me
> "push the current branch back to where it came from" seems like far more
> a rational default for at least 90% of users.
"git remote <remote> push" for push matching?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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