* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Arjen Laarhoven @ 2008-10-17 7:02 UTC (permalink / raw)
To: Pieter de Bie
Cc: Brandon Casey, Jeff King, Junio C Hamano, git, Shawn O. Pearce,
Mike Ralphson
In-Reply-To: <465E8DD6-CBDC-4E02-9C7F-57CBE81E3549@frim.nl>
On Thu, Oct 16, 2008 at 05:37:10PM +0200, Pieter de Bie wrote:
>
> On 16 okt 2008, at 17:21, Brandon Casey wrote:
>
> >Darwin, anyone?
>
> 'maint' passes for me on Darwin (OS X Leopard) after removing the
> regex stuff in Makefile
Yup, confirmed.
Arjen
--
Arjen Laarhoven
The presence of those seeking the truth is infinitely to be preferred to
those who think they've found it.
-- Terry Pratchett, "Monstrous Regiment"
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-17 7:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ljwojeeu.fsf@localhost.localdomain>
On Fri, Oct 17, 2008 at 01:42, Jakub Narebski <jnareb@gmail.com> wrote:
> [a lot of detailed information]
Thanks! 'Unfortunately', I figured all this out by myself, in the
meantime, but I really appreciate that you took the time to
explain all this .
Thanks!
Richard
PS: Well, I lie, I did not figure out the mv $1.sample $1 bit
as my git version still uses the old format.
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-17 7:33 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Peter Harris, git
In-Reply-To: <48F7BBAC.2090907@xiplink.com>
Marc Branchaud venit, vidit, dixit 17.10.2008 00:09:
> Peter Harris wrote:
>> Ah. I believe I misunderstood what you wanted. Perhaps you want "git
>> remote add", then? Unfortunately, you have to know what your remotes
>> are outside of git for this. Perhaps a script in the root of your
>> repository you can run to set this up after the initial clone?
>
> I think we're converging onto the same track.
>
> Yes, I do want to use "git remote add". My point is basically that,
> having done various git-remote-adds in the main repository, I'd like to
> avoid having to redo them in a clone of that repository.
>
> A script would work, sure, but to me this seems like something git
> should handle for me. If I have to re-establish my connections to the
> remotes whenever I want to pull in updates, then I don't see much point
> in keeping the remotes defined in any git repo.
>
>> I seem to recall some discussion of allowing a .gitconfig to be in
>> repositories (similar to .gitignore), but the idea was shot down for
>> security reasons.
>
> I think I can understand why that would be undesirable, but I don't know
> if something like that would be necessary for what I'm talking about.
I don't think there is a direct gittish way for transferring the remote
config from one repo to a clone (other than copying what git submodule
does with .gitmodules etc.).
Would it be sufficient for you if a clone could trigger the main repo to
update its remotes (i.e. git remote update)?
Michael
^ permalink raw reply
* Weird filename encoding issue
From: Alexander Gladysh @ 2008-10-17 7:59 UTC (permalink / raw)
To: msysgit, git
[-- Attachment #1: Type: text/plain, Size: 105 bytes --]
Hi, all!
OS X 10.5.5 (English locale), Git 1.5.5.1
Windows XP SP2 (Russian), msysGit 1.5.6.1.1071.g76fb
[-- Attachment #2: Copy.zip --]
[-- Type: application/zip, Size: 116 bytes --]
^ permalink raw reply
* Re: Weird filename encoding issue
From: Alexander Gladysh @ 2008-10-17 8:08 UTC (permalink / raw)
To: msysgit, git
In-Reply-To: <c6c947f60810170059s3859d906r9935b5e80d8a41c6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
On Fri, Oct 17, 2008 at 11:59 AM, Alexander Gladysh <agladysh@gmail.com> wrote:
> Hi, all!
>
> OS X 10.5.5 (English locale), Git 1.5.5.1
> Windows XP SP2 (Russian), msysGit 1.5.6.1.1071.g76fb
My apologies, Gmail eaten part of my message.
Sorry for such old Git versions, I can not upgrade right now. Perhaps
it was fixed in 1.6.x?
Steps to reproduce:
1. Create git repo on Windows machine, add there file, named
"Копия.txt" (Russian for Copy.txt) in CP1251 (NOT UTF-8). Just in
case, hopefully correctly named file is attached.
File must be added and committed from git gui, not from command line.
$ mkdir test && cd test
$ git init
<put file there>
$ git gui
2. Share the repo somewhere, so it would be accessible from OS X (repo
should still be on Windows machine).
3. Clone repo to OS X machine and see the weird behaviour. Git status
can't decide how file should be named, "%CA%EE%EF%E8%FF.txt" or
"\312\356\357\350\377.txt".
$ git clone /Volumes/Exchange/test/
Initialized empty Git repository in /Users/agladysh/test/.git/
$ cd test
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# %CA%EE%EF%E8%FF.txt
nothing added to commit but untracked files present (use "git add" to track)
$ ls
%CA%EE%EF%E8%FF.txt
$ git clean -fd
Removing %CA%EE%EF%E8%FF.txt
$ git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: "\312\356\357\350\377.txt"
#
no changes added to commit (use "git add" and/or "git commit -a")
Alexander.
[-- Attachment #2: Copy.zip --]
[-- Type: application/zip, Size: 116 bytes --]
^ permalink raw reply
* Re: --diff-filter=T does not list x changes
From: Junio C Hamano @ 2008-10-17 8:29 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Jeff King, git
In-Reply-To: <87ej2fvgv9.fsf@kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> That documentation is quite loosely written. Typechange diff is what
>> T has always meant, and it never was about the executable bit. The
>> word "mode" in that sentence only means the upper bits
>> S_IFREG/S_IFLNK (iow, masked by S_IFMT).
>
> I hope you agree that this reading is not obvious from the
> documentation,...
Yup, didn't I already say that the documentation is buggy?
> How about adding a diff-filter=X for the executable bit?
I do not think it is a good idea for two reasons. Backward compatibility
and sane design.
For one thing, "diff --name-status" never shows X, so you would introduce
an unnecessary inconsistency. If you change "--name-status" to avoid
that, you would be breaking people's existing scripts that expect to see
"M" for such a change.
Even if you were forgiven by these people whose scripts are broken by your
change, you need to decide between "M" and "X" when both contents and
executable bit are changed. The least surprising logic would probably be
to show "X" when _only_ executable bit is changed and show "M" when
contents changed (even when executable bit also did), but that feels quite
arbitrary. And the other way around isn't any better.
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Junio C Hamano @ 2008-10-17 8:37 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com>
"Richard Hartmann" <richih.mailinglist@gmail.com> writes:
>> (2) pre-commit hook is a last ditch effort to help ignorant
>> users who have already done "git add" without thinking and
>> lost the "unmerged" state. It has to look at and guess at
>> the contents for that.
>
> Ignoring the ad hominem attack, I would argue that the two
Eh, Sorry about that --- I did not mean "ignorant" in that sense. Perhaps
replacing the word with "unfortunate" would sound nicer?
> To err is human, which is why rm -i exists. Else, you could
> just use alias rm='rm -rf'.
>
> Also, within certain boundaries, a tool should adapt to the
> user, not vice versa.
Don't you realize that is what the hook is doing already? After making
such an error, the definitive information is lost, because the user told
the tool that the resolution is done and the file is ready to be
committed) by mistake. Even then the hook is trying its best to help the
user.
Replace your "rm=rm -rf" sentence with "why undelete exists" and read it
again. No, filesystem undelete does not always work (disk block could
have been recycled for other files), but it could help you when you did
remove a file you wanted to keep by mistake when it can.
As to pre-add hook, I am not enthused, but if somebody sends in a clean
patch, I wouldn't be opposed to it at least in principle.
^ permalink raw reply
* Re: Weird filename encoding issue
From: Johannes Sixt @ 2008-10-17 8:55 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: msysgit, git
In-Reply-To: <c6c947f60810170108q3038b66bj2ad89bdcb7105903@mail.gmail.com>
Alexander Gladysh schrieb:
> 3. Clone repo to OS X machine and see the weird behaviour. Git status
> can't decide how file should be named, "%CA%EE%EF%E8%FF.txt" or
> "\312\356\357\350\377.txt".
It's not 'git status' that cannot decide how to name the file. It's OS X.
> $ git status
> # On branch master
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # %CA%EE%EF%E8%FF.txt
> nothing added to commit but untracked files present (use "git add" to track)
> $ ls
> %CA%EE%EF%E8%FF.txt
git asked OS X:
Does the file "\312\356\357\350\377.txt" exist?
and OS X said: "Yes". Because otherwise, you would have seen the file
listed as "deleted:" in the 'git status' call above.
But then git also requested a file listing from OS X in order to list the
untracked files. And now OS X returned the name "%CA%EE%EF%E8%FF.txt". How
could you expect git to tell that this is the same file when OS X cannot
decide how to name it?
The solution: Do not use file names with some local (let alone Windows
specific) encoding if you have to use the files on OS X, too.
-- Hannes
^ permalink raw reply
* Re: Weird filename encoding issue
From: Jakub Narebski @ 2008-10-17 8:57 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: msysgit, git
In-Reply-To: <c6c947f60810170108q3038b66bj2ad89bdcb7105903@mail.gmail.com>
"Alexander Gladysh" <agladysh@gmail.com> writes:
> Steps to reproduce:
>
> 1. Create git repo on Windows machine, add there file, named
> "Копия.txt" (Russian for Copy.txt) in CP1251 (NOT UTF-8). Just in
> case, hopefully correctly named file is attached.
>
> File must be added and committed from git gui, not from command line.
>
> $ mkdir test && cd test
> $ git init
> <put file there>
> $ git gui
>
> 2. Share the repo somewhere, so it would be accessible from OS X (repo
> should still be on Windows machine).
>
> 3. Clone repo to OS X machine and see the weird behaviour. Git status
> can't decide how file should be named, "%CA%EE%EF%E8%FF.txt" or
> "\312\356\357\350\377.txt".
I _suspect_ that it is caused by known issue with MacOS X filesystem
in default settings. Git assumes that what he puts in filesystem is
the same that it reads from filesystem; there is ongoing (although
bit stalled) effort to make Git work around this. Unfortunately HFS+
does not, I think, fullfil this requirement.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Jakub Narebski @ 2008-10-17 9:16 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Junio Hamano, Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com>
"Richard Hartmann" <richih.mailinglist@gmail.com> writes:
> On Fri, Oct 17, 2008 at 01:39, Junio Hamano <junio@twinsun.com> wrote:
> > (2) pre-commit hook is a last ditch effort to help ignorant
> > users who have already done "git add" without thinking and
> > lost the "unmerged" state. It has to look at and guess at
> > the contents for that.
>
> Ignoring the ad hominem attack, I would argue that the two
> distinct mental concepts of 'I want to commit this in the next
> commit' and 'I have resolved this conflict' should have two
> distinct commands.
>
> To err is human, which is why rm -i exists. Else, you could
> just use alias rm='rm -rf'.
>From time to time somebody proposes to add a command which is used
only to say that given conflict got resolved, i.e. yet another
porcelain "around" git-update-index plumbing (in addition to git-add,
git-mv and git-rm). One of problems is how to call it: git-resolve,
git-resolved, git-mark-resolved?
BTW. while I usually use "git commit -a", when comitting merge commit
I usually use explicit "git add" together "git commit" (without '-a').
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git hooks are not called over HTTP
From: Jakub Narebski @ 2008-10-17 9:22 UTC (permalink / raw)
To: KwangYul Seo; +Cc: git
In-Reply-To: <7beb12420810162323o6dce0a71r897fbed9b9d3e417@mail.gmail.com>
"KwangYul Seo" <kwangyul.seo@gmail.com> writes:
> I have setup a git repository with post-receive and post-update
> enabled. I configured hooks.envelopesender and hooks.mailinglist. I
> confirmed that it works fine with push from local repositories.
> However, hooks are never called when push is done over HTTP. I added
> 'echo abc' to post-receive to see if it is called or not. With local
> push, abc was printed, but with HTTP push it was not printed. What is
> the problem here?
The "problem" here (which is very much the way HTTP protocol was
designed) is that it isn't _git_ that updates repository on remote
side on push (which knows about hooks), but _web server_ via WebDAV.
And web server knows nothing about hooks.
Perhaps that would get improved when "smart" HTTP protocol gets
implemented (currently in the phase of design, I think just after
designing protocol).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-17 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <7vwsg7mxb6.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 17, 2008 at 10:37, Junio C Hamano <gitster@pobox.com> wrote:
> Eh, Sorry about that --- I did not mean "ignorant" in that sense. Perhaps
> replacing the word with "unfortunate" would sound nicer?
A lot yes. No harm done, apologies for picking the bad interpretation
of ignorant.
> Don't you realize that is what the hook is doing already? After making
> such an error, the definitive information is lost, because the user told
> the tool that the resolution is done and the file is ready to be
> committed) by mistake. Even then the hook is trying its best to help the
> user.
You misunderstood me, there. I was thinking about the pre-add hook
while writing the above. Doing anything at commit time is obviously
wrong.
> As to pre-add hook, I am not enthused, but if somebody sends in a clean
> patch, I wouldn't be opposed to it at least in principle.
An implicit need for it does apparently exist. Else, the default hook for
pre-commit would not need to check for conflicts.
Richard
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-17 9:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio Hamano, Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <m3d4hzk2du.fsf@localhost.localdomain>
On Fri, Oct 17, 2008 at 11:16, Jakub Narebski <jnareb@gmail.com> wrote:
> From time to time somebody proposes to add a command which is used
> only to say that given conflict got resolved, i.e. yet another
> porcelain "around" git-update-index plumbing (in addition to git-add,
> git-mv and git-rm). One of problems is how to call it: git-resolve,
> git-resolved, git-mark-resolved?
In that case, you would still need a pre-add hook.
The problem is not that people can't mark resolved without adding.
It's that they can't add without checking (automatically) if there
are no conflicts.
Richard
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Junio C Hamano @ 2008-10-17 9:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Richard Hartmann, Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <m3d4hzk2du.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> From time to time somebody proposes to add a command which is used
> only to say that given conflict got resolved, i.e. yet another
> porcelain "around" git-update-index plumbing (in addition to git-add,
> git-mv and git-rm). One of problems is how to call it: git-resolve,
> git-resolved, git-mark-resolved?
>
> BTW. while I usually use "git commit -a", when comitting merge commit
> I usually use explicit "git add" together "git commit" (without '-a').
There are three things to keep in mind while thinking about this:
* "git add" _always_ is to mark "this path now is in a good shape and is
ready to be committed", whether you are doing a conflict resolution of
a merge or making a normal commit.
* you cannot partially commit a merge, as the resulting tree won't be a
proper merge (i.e. the change from either parents do not describe what
happened).
* during a conflicted merge, cleanly merged paths are already staged in
the index.
Which means that the only paths you would "git add" during a conflicted
merge are the paths you resolved (unless you are creating an evil merge),
and there is no point having a separate "git resolved" -- such a command
will be nothing but an alias to "git add" anyway.
We could add a training wheel mode to "git commit -a" (or "git add -u")
that warns about unmerged paths and asks confirmation, but I suspect that
it would really annoy people who used git for more than 2 weeks if we made
it the default, and on the other hand if it is not the default, it would
not help new people that much. It is nice to try to help new people from
shooting themselves in the foot, but we need to draw a line somewhere so
that we do not hurt people by being obnoxious. After all, even these new
people will graduate from the "new" status soon. My gut feeling is that
helping "oh, I staged the file that I wasn't ready to commit" is on the
other side of that line, especially since the example pre-commit hook
safety is easily available. If somebody wants to add a pre-add hook that
is run by "git add" Porcelain (but never by "update-index"), that would
add the safety net, too.
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Jeff King @ 2008-10-17 9:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vej2i7rt9.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 14, 2008 at 03:08:50PM -0700, Junio C Hamano wrote:
> * The 'master' branch has these since the last announcement
> in addition to the above.
>
> Jeff King (1):
> tests: shell negation portability fix
Can you cherry-pick this into maint? The problem it fixes was caused by
969c877, which is in maint (IOW, master is fixed, but maint is still
broken).
-Peff
^ permalink raw reply
* git-commit does not signoff using name supplied by --author
From: bain @ 2008-10-17 10:11 UTC (permalink / raw)
To: git
Hi all,
If i use git-commit --author "A U Thor <author.example.net>" -s it
still uses my global author.name and author.email to add signoff
message.
Is this expected behavior?
thanks
BAIN
^ permalink raw reply
* Re: git-commit does not signoff using name supplied by --author
From: bain @ 2008-10-17 10:31 UTC (permalink / raw)
To: git
In-Reply-To: <6a7ddf4e-8fcb-4a39-b4c5-1396cf702c8b@f40g2000pri.googlegroups.com>
> If i use git-commit --author "A U Thor <author.example.net>" -s it
> still uses my global author.name and author.email to add signoff
> message.
>
> Is this expected behavior?
Never mind...
Looking at the code i found out commiter name/email is used to
signoff, which is correct and can be different than author.
BAIN
^ permalink raw reply
* Removing some files from history
From: Gennady Kushnir @ 2008-10-17 10:38 UTC (permalink / raw)
To: git
Hello all
I'm not yet subscribed, but I wish I shall get reply anyway
I'm going to make my repository public, but I have found that one of
my files contains some private data that I would not like to share.
Is it possible to remove that file from all commits in my local
repository history before publishing it?
Or it would be easier to start publishing with just my current state
(whith all private data cleaned up)?
Thanks in advance.
Gennady
^ permalink raw reply
* Re: Removing some files from history
From: Jeff King @ 2008-10-17 10:42 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: git
In-Reply-To: <96ed5eac0810170338s292fe858s1c092428a44a7ad2@mail.gmail.com>
On Fri, Oct 17, 2008 at 02:38:54PM +0400, Gennady Kushnir wrote:
> I'm going to make my repository public, but I have found that one of
> my files contains some private data that I would not like to share.
> Is it possible to remove that file from all commits in my local
> repository history before publishing it?
Yes, see "git help filter-branch". The first example given does exactly
what you are asking for.
-Peff
^ permalink raw reply
* Re: Removing some files from history
From: Michael J Gruber @ 2008-10-17 10:52 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: git
In-Reply-To: <96ed5eac0810170338s292fe858s1c092428a44a7ad2@mail.gmail.com>
Gennady Kushnir venit, vidit, dixit 17.10.2008 12:38:
> Hello all
> I'm not yet subscribed, but I wish I shall get reply anyway
>
> I'm going to make my repository public, but I have found that one of
> my files contains some private data that I would not like to share.
> Is it possible to remove that file from all commits in my local
> repository history before publishing it?
> Or it would be easier to start publishing with just my current state
> (whith all private data cleaned up)?
>
> Thanks in advance.
> Gennady
Use
git filter-branch --index-filter 'git rm --cached secret' -- --all
or
git filter-branch --tree-filter 'rm -f secret' -- --all
where 'secret' is the name of the file to be removed.
After that, make sure you clean up your repo before publishing:
Clean out the original references (command on 1 line):
git for-each-ref --format='%(refname)' refs/original |while read ref;
do git update-ref -d $ref;done
Clean out the reflog:
git reflog --expire=0 expire
Remove the old objects and packs:
git prune
git repack -adf
[Makes me feel this should be easier.]
Michael
^ permalink raw reply
* Re: [PATCH] fix guilt-pop and push to fail if no relevant patches
From: Scott Moser @ 2008-10-17 11:37 UTC (permalink / raw)
To: Josef 'Jeff' Sipek; +Cc: git
In-Reply-To: <1222714293-9680-1-git-send-email-smoser@brickies.net>
Jeff,
Did you not like the patch below for some reason ?
It seemed fairly straightforward to me that guilt-pop and guilt-push
should exit failure if they did not do anything due to having nothing to
do.
On Mon, 29 Sep 2008, Scott Moser wrote:
> currently guilt-pop and guilt-push will exit with '0' if there are no more
> relevant patches in the series (ie, if you've pushed or popped all of them)
>
> This means that you cannot do something like:
> while guilt-push; do
> guilt refresh || break
> done
>
> for reference, quilt does exit with non-zero in those cases:
> $ quilt push -a && quilt push
> File series fully applied, ends at patch my.patch
> $ echo $?
> 1
>
> $ quilt pop -a; quilt pop
> No patch removed
> $ echo $?
> 2
>
> Signed-off-by: Scott Moser <smoser@brickies.net>
> ---
> guilt-pop | 3 +--
> guilt-push | 43 ++++++++++++++++++++++++-------------------
> regression/t-021.out | 3 +++
> 3 files changed, 28 insertions(+), 21 deletions(-)
>
> diff --git a/guilt-pop b/guilt-pop
> index db8473e..8a83fdb 100755
> --- a/guilt-pop
> +++ b/guilt-pop
> @@ -45,8 +45,7 @@ patch="$1"
> [ ! -z "$all" ] && patch="-a"
>
> if [ ! -s "$applied" ]; then
> - disp "No patches applied."
> - exit 0
> + die "No patches applied."
> elif [ "$patch" = "-a" ]; then
> # we are supposed to pop all patches
>
> diff --git a/guilt-push b/guilt-push
> index 018f9ac..48f886b 100755
> --- a/guilt-push
> +++ b/guilt-push
> @@ -97,22 +97,27 @@ fi
> sidx=`wc -l < $applied`
> sidx=`expr $sidx + 1`
>
> -get_series | sed -n -e "${sidx},${eidx}p" | while read p
> -do
> - disp "Applying patch..$p"
> - if [ ! -f "$GUILT_DIR/$branch/$p" ]; then
> - die "Patch $p does not exist. Aborting."
> - fi
> -
> - push_patch "$p" $abort_flag
> -
> - # bail if necessary
> - if [ $? -eq 0 ]; then
> - disp "Patch applied."
> - elif [ -z "$abort_flag" ]; then
> - die "Patch applied with rejects. Fix it up, and refresh."
> - else
> - die "To force apply this patch, use 'guilt push -f'"
> - fi
> -done
> -
> +get_series | sed -n -e "${sidx},${eidx}p" |
> + {
> + did_patch=0
> + while read p
> + do
> + disp "Applying patch..$p"
> + if [ ! -f "$GUILT_DIR/$branch/$p" ]; then
> + die "Patch $p does not exist. Aborting."
> + fi
> +
> + push_patch "$p" $abort_flag
> +
> + # bail if necessary
> + if [ $? -eq 0 ]; then
> + disp "Patch applied."
> + elif [ -z "$abort_flag" ]; then
> + die "Patch applied with rejects. Fix it up, and refresh."
> + else
> + die "To force apply this patch, use 'guilt push -f'"
> + fi
> + did_patch=1
> + done
> + [ $did_patch -ge 1 ] || die "no patches to apply"
> + }
> diff --git a/regression/t-021.out b/regression/t-021.out
> index cd8ae96..44771cb 100644
> --- a/regression/t-021.out
> +++ b/regression/t-021.out
> @@ -822,6 +822,7 @@ index 0000000..8baef1b
> @@ -0,0 +1 @@
> +abc
> % guilt-push --all
> +no patches to apply
> % guilt-pop -n -1
> Invalid number of patches to pop.
> % list_files
> @@ -908,6 +909,7 @@ index 0000000..8baef1b
> @@ -0,0 +1 @@
> +abc
> % guilt-push --all
> +no patches to apply
> % guilt-pop -n 0
> No patches requested to be removed.
> % list_files
> @@ -994,6 +996,7 @@ index 0000000..8baef1b
> @@ -0,0 +1 @@
> +abc
> % guilt-push --all
> +no patches to apply
> % guilt-pop -n 1
> Now at remove.
> % list_files
> --
> 1.5.6.3
>
>
> !DSPAM:48e123ca138521410093335!
>
>
^ permalink raw reply
* Re: Removing some files from history
From: Gennady Kushnir @ 2008-10-17 11:51 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48F86E6A.7080102@fastmail.fm>
thank you for precise instructions.
however I did not completely understand the part about references and reflog
what are these? git tags?
and another question:
did I understand it right, that I can even make some changes to that
file in history - not just simply delete one?
Gennady
2008/10/17 Michael J Gruber <michaeljgruber+gmane@fastmail.fm>:
> Gennady Kushnir venit, vidit, dixit 17.10.2008 12:38:
>> Hello all
>> I'm not yet subscribed, but I wish I shall get reply anyway
>>
>> I'm going to make my repository public, but I have found that one of
>> my files contains some private data that I would not like to share.
>> Is it possible to remove that file from all commits in my local
>> repository history before publishing it?
>> Or it would be easier to start publishing with just my current state
>> (whith all private data cleaned up)?
>>
>> Thanks in advance.
>> Gennady
> Use
>
> git filter-branch --index-filter 'git rm --cached secret' -- --all
>
> or
>
> git filter-branch --tree-filter 'rm -f secret' -- --all
>
> where 'secret' is the name of the file to be removed.
>
> After that, make sure you clean up your repo before publishing:
> Clean out the original references (command on 1 line):
>
> git for-each-ref --format='%(refname)' refs/original |while read ref;
> do git update-ref -d $ref;done
>
> Clean out the reflog:
>
> git reflog --expire=0 expire
>
> Remove the old objects and packs:
>
> git prune
> git repack -adf
>
> [Makes me feel this should be easier.]
>
> Michael
>
^ permalink raw reply
* Re: Removing some files from history
From: Jakub Narebski @ 2008-10-17 12:20 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: Michael J Gruber, git
In-Reply-To: <96ed5eac0810170451y69fd864jb44ef62bca468498@mail.gmail.com>
Please do not toppost, and quote only fragments you are replying to.
"Gennady Kushnir" <genkush@rujel.net> writes:
> thank you for precise instructions.
>
> however I did not completely understand the part about references
> and reflog what are these? git tags?
git-filter-branch saves old version under refs/original/* namespace.
You have to remove them after making sure that your rewritten history
is correct.
Additionally git keeps log where branch (tip/head of branch) was in
your repository; this is kind of generalization of ORIG_HEAD, and
allows to recover from such mistakes as wrong "git reset --hard".
Reflog entries from your original history also would pin commits, so
you have to expire reflog.
And finally the commits you have are there in repository, so you have
to "prune" repository to get rid of them. Reflog entries and
refs/original/* pin those commits, so you have to remove them prior to
pruning. Pruning simply removes objects which are unreferenced.
> and another question:
> did I understand it right, that I can even make some changes to that
> file in history - not just simply delete one?
Yes, see man git-filter-branch.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git hooks are not called over HTTP
From: Shawn O. Pearce @ 2008-10-17 14:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: KwangYul Seo, git
In-Reply-To: <m38wsnk24l.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> "KwangYul Seo" <kwangyul.seo@gmail.com> writes:
>
> > I have setup a git repository with post-receive and post-update
> > enabled. I configured hooks.envelopesender and hooks.mailinglist. I
> > confirmed that it works fine with push from local repositories.
> > However, hooks are never called when push is done over HTTP.
>
> Perhaps that would get improved when "smart" HTTP protocol gets
> implemented (currently in the phase of design, I think just after
> designing protocol).
Yes. The Git-in-HTTP protocol for push basically calls for an
embedding of send-pack/receive-pack's protocol into HTTP, and
implementation wise will probably be invoking git-receive-pack on
the web server side of the connection. So if/when that finally
gets implemented we'd run hooks over HTTP, but *ONLY* if both sides
support the new Git-in-HTTP protocol.
If both sides are still using WebDAV, no hooks, for the reason you
cited earlier.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fix guilt-pop and push to fail if no relevant patches
From: Josef 'Jeff' Sipek @ 2008-10-17 14:28 UTC (permalink / raw)
To: Scott Moser; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810170736240.27798@brickies>
On Fri, Oct 17, 2008 at 07:37:33AM -0400, Scott Moser wrote:
> Jeff,
> Did you not like the patch below for some reason ?
I don't remember my train of thought, but I ended up making a simpler patch
to address the push-pushing-more-than-it-should bug. I completely missed the
part about the exit codes.
> It seemed fairly straightforward to me that guilt-pop and guilt-push
> should exit failure if they did not do anything due to having nothing to
> do.
I'd actually say that it's not obvious, but...see below :)
> On Mon, 29 Sep 2008, Scott Moser wrote:
> > currently guilt-pop and guilt-push will exit with '0' if there are no more
> > relevant patches in the series (ie, if you've pushed or popped all of them)
> >
> > This means that you cannot do something like:
> > while guilt-push; do
> > guilt refresh || break
> > done
> >
> > for reference, quilt does exit with non-zero in those cases:
> > $ quilt push -a && quilt push
> > File series fully applied, ends at patch my.patch
> > $ echo $?
> > 1
> >
> > $ quilt pop -a; quilt pop
> > No patch removed
> > $ echo $?
> > 2
Who am I to argue against compatibility.
...
> > diff --git a/guilt-push b/guilt-push
> > index 018f9ac..48f886b 100755
> > --- a/guilt-push
> > +++ b/guilt-push
[snipped long diff]
With my fix, this should be a 2-liner :)
Sorry for missing the return code part...
Josef 'Jeff' Sipek.
--
We have joy, we have fun, we have Linux on a Sun...
^ 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