Add -n (dryrun) flag to git-prune-packed, and call it from "git prune".
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-prune-script |6 --
prune-packed.c | 16
2 files changed, 16 insertions(+), 6 deletions(-)
51890a64eb152fb914d0dd3676f549ab8d8cc49a
dif
Junio C Hamano <[EMAIL PROTECTED]> writes:
> *1* I should probably write a bit about how I do things in a
> separate message as a how-to.
So here it is.
Note that the version of git on my $PATH is usually the one from
the proposed updates branch, so some of the commands I use in
the following te
Hi,
On Sat, 20 Aug 2005, Paul Mackerras wrote:
> Hmmm... now I suppose we want a way to use gitk to drive the git
> bisection process... :)
Ssshh! Let sleeping dogs lie! ;-)
Ciao,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED
Junio C Hamano writes:
> If you can pop-up a temporary window that shows the tag contents
> when I hover over a tag icon for 2 seconds, and remove that
> temporary window when step outside it would be ideal. It is up
I did something a little easier - if you click on the tag, it now
displays the
Currently, typing `git pull' without a third argument will result in an
error message. Make it default to orgin, which is what the user
typically means.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
git-pull-script | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
d
On Fri, 2005-08-19 at 20:27 +0200, Jan Veldeman wrote:
> hmm, not exactly, for example, when reordering the patches (including the
> top one), I would like to see this in gitk.
> Or when a patch has been dropped (amongst a lot of patches), it should be
> easily spotted.
I tried your patch but the
This teachs git-applypatch, which is used from git-applymbox, three
hooks, similar to what git-commit-script uses.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
This is still in the proposed updates branch, along with the
hooks for "git commit". Are people comfortable with the
I humbly appreciate your patch, sir. I am really sorry to be in
the position of having to tell you this, but earlier the Emperor
Penguin himself gave me this shiny blue baseball bat and told me
to show it to any deserving person. Could you please come
closer and kindly extend your neck a little b
Jason Riedy <[EMAIL PROTECTED]> writes:
> And Junio C Hamano writes:
> - It turns out that your patch breaks GCC build
>
> Whoops, sorry. Your fix works with Sun's cc.
Thanks.
> BTW, how would people feel about replacing the
> setenv() and unsetenv() calls with the older putenv()?
> The So
Linus Torvalds <[EMAIL PROTECTED]> writes:
> However, one thing to look out for is that if you've marked any files for
> update (with git-update-cache) those will always be committed regardless
> of what arguments you give to "git commit".
Another thing to look out for is that the files you tol
Catalin Marinas wrote:
>
> The patch history feature was available in StGIT 0.1/0.2 releases
> where you should have run a 'stg commit' before 'stg refresh'. The
> commit was handling all the history changes, with separate commit
> messages and refresh was updating the main commit with 2 parents.
When following tags, check for parse_object() success and error out
properly instead of segfaulting.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
---
rev-list.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
f4ec41063d2f43b06b7c8e511108b4c9bf9e6ebe
diff --git a/rev-list.c b/rev
Catalin Marinas wrote:
>
> The patch history feature was available in StGIT 0.1/0.2 releases
> where you should have run a 'stg commit' before 'stg refresh'. The
> commit was handling all the history changes, with separate commit
> messages and refresh was updating the main commit with 2 parents.
Ah, that explains it. I had already marked all my changes for update,
that's what threw me off here. Thanks!
Linus Torvalds wrote:
On Fri, 19 Aug 2005, Johnny Stenback wrote:
That made me assume that if I do:
git-commit-script somedir
it would *only* commit the changes I've made in "some
On Fri, 19 Aug 2005, Johnny Stenback wrote:
>
> That made me assume that if I do:
>
>git-commit-script somedir
>
> it would *only* commit the changes I've made in "somedir", but it
> appears to commit *all* files that have changed (and shows all files in
> the list of changed files in th
Hey all,
git-commit-script --help says:
git commit [-a] [-m ] [-F ] [(-C|-c) ]
[...]
That made me assume that if I do:
git-commit-script somedir
it would *only* commit the changes I've made in "somedir", but it
appears to commit *all* files that have changed (and shows all files in
the
On Fri, 19 Aug 2005, Martin Langhoff wrote:
> On 8/19/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> > Martin Langhoff <[EMAIL PROTECTED]> writes:
> >
> > > If I remember correctly, Junio added some stuff in the merge & rebase
> > > code that will identify if a particular patch has been seen and
On Fri, 19 Aug 2005, Martin Langhoff wrote:
> After using arch for a while, I've gotten used to getting .rej and
> .orig files instead of big ugly conflict markers inside the file.
> Emacs has a nice 'diff' mode that is a boon when dealing with
> conflicts this way.
>
> Is there a way to convince
Hi,
I tried to compile & run git on cygwin. Two showstoppers:
- cygwin does not support IPv6 (yet). Therefore, it does
not have getaddrinfo() and friends. (minor showstopper)
- fork() and mmap() together have problems. This manifests
itself in "git-diff-tree -
On Fri, 19 Aug 2005, Martin Langhoff wrote:
>
> I'm keen on keeping my 'merge & publish' step in a single repo that
> has all the 'team' branches. The person running this repo will
> probably actually code in separate repos, and merge in there too.
I would suggest against a person owning a "mer
And Junio C Hamano writes:
- It turns out that your patch breaks GCC build
Whoops, sorry. Your fix works with Sun's cc.
BTW, how would people feel about replacing the
setenv() and unsetenv() calls with the older putenv()?
The Solaris version I have to work on doesn't have
the nicer functio
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> Hi,
>
> If I understand correctly, the multi-head fetch would not write any ref if
> used like this:
>
> git fetch remote:repository/ head tail
>
> but it would try a fast-forward when used like this:
>
> git fetch remote:repository/ h
Quick note: I'm working on importing from SVN.
My current main problem is that SVN's Perl interface leaks server
connections (apparently nobody has used it for any real work yet),
which is of course *bad*, and kindof prevents me from finishing
the job today. :-/
--
Matthias Urlichs | {M:U} I
Jan Veldeman <[EMAIL PROTECTED]> wrote:
> I like stgit very much, but I feel there is still something missing:
> stgit is very handy when you use it for patches which should be pushed to
> mainline rather quickly. But for pacthes which won't be pushed immediately
> to mainline, it would be usefull
Hi,
If I understand correctly, the multi-head fetch would not write any ref if
used like this:
git fetch remote:repository/ head tail
but it would try a fast-forward when used like this:
git fetch remote:repository/ head:head tail:tail
Correct? If yes: This is fantastic! It ob
Jason Riedy <[EMAIL PROTECTED]> writes:
> Sun's cc doesn't know __attribute__.
It turns out that your patch breaks GCC build (#ifndef
__attribute__ is true there, and it should be---what it does
cannot be done in preprocessor alone). I am going to work it
around like this. Could you try it with
On 8/19/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Martin Langhoff <[EMAIL PROTECTED]> writes:
>
> > If I remember correctly, Junio added some stuff in the merge & rebase
> > code that will identify if a particular patch has been seen and
> > applied, and skip it even if it's a bit out of ord
Hi,
On Fri, 19 Aug 2005, Martin Langhoff wrote:
> Each patchset has a unique identifier, and can carry metadata with the
> identifiers of the patches it "includes". If you are using gnu arch,
> when you merge across branches, it'll know to skip a particular
> patchset if it has been applied alrea
Martin Langhoff <[EMAIL PROTECTED]> wrote:
> After using arch for a while, I've gotten used to getting .rej and
> .orig files instead of big ugly conflict markers inside the file.
> Emacs has a nice 'diff' mode that is a boon when dealing with
> conflicts this way.
>
> Is there a way to convince co
Hi,
On Thu, 18 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <[EMAIL PROTECTED]> writes:
>
> >> The patch is for people who thinks the user who uses the "--all"
> >> flag deserves the danger that comes with the convenience.
> >>
> >> Comments?
> >
> > This is a sane default behaviour. M
In case of empty messages git-mailinfo ignores the "---"
line adding dirty stuff in commit message otherwise empty
Signed-off-by: Marco Costalba <[EMAIL PROTECTED]>
---
tools/mailinfo.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
1ebfddf05e4655811157028091d03dfce39cc4f0
dif
Martin Langhoff <[EMAIL PROTECTED]> writes:
> If I remember correctly, Junio added some stuff in the merge & rebase
> code that will identify if a particular patch has been seen and
> applied, and skip it even if it's a bit out of order. But I don't know
I think you are talking about git-patch-id
The current "pu" branch has most of the necessary plumbing for
multi-head fetching, pulling and creating Octopus merges based
on multiple heads. I have made "git pull" multi-head aware but
did not make it multi-head capable.
I have been trying out Tony Luck's excellent topic-branch
workflow (see
The syntax for .PRECIOUS in a makefile requires
an implicit target to match exactly:
%.txt does not cover all *.txt
Signed-off-by: Kris Shannon <[EMAIL PROTECTED]>
---
Documentation/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile b/
I am drafting an import script to turn a GNU Arch into a GIT archive.
Importing the branches and commits increamentally is reasonably
straightforward -- or so it seems so far. Note: the repository
manipulation is based on cvsimport -- so my knowledge of the git repo
internals is still pertty close
35 matches
Mail list logo
