* 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
* Re: [PATCH] fix guilt-pop and push to fail if no relevant patches
From: Scott Moser @ 2008-10-17 14:40 UTC (permalink / raw)
To: Josef 'Jeff' Sipek; +Cc: git
In-Reply-To: <20081017142832.GF27647@josefsipek.net>
On Fri, 17 Oct 2008, Josef 'Jeff' Sipek wrote:
> 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.
>
good enough. I hadn't pulled in a while and didn't realize you'd made a
change. I never actually saw a problem with "pushing too much" , but
only in the exit codes.
> > > 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 :)
for what its worth, the patch i sent only added a couple lines. It
really just changed indentation. So, the patch was long, only 2 new
lines that did anything.
anyway... I'm happy if you make it exit failure.
Thanks,
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-17 14:44 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Peter Harris, git
In-Reply-To: <48F83FD0.90606@drmicha.warpmail.net>
Thanks for joining the thread, Michael!
Michael J Gruber wrote:
>
> 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.).
That's my impression, too, so I'm suggesting that the clone/push/pull
commands get an option to work with remotes in config.
> Would it be sufficient for you if a clone could trigger the main repo to
> update its remotes (i.e. git remote update)?
Hmmm, I'm not sure... How would the overall
merge-in-changes-from-upstream process work in that case?
Say the main repo has the code for "ThingOne" merged under a top-level
thing-one/ directory:
main/$ git remote add -f ThingOne git://thing/ThingOne.git
main/$ git merge -s ours --no-commit ThingOne/master
main/$ git read-tree --prefix=thing-one/ -i ThingOne/master
main/$ git commit -m "Merged ThingOne into /thing-one/"
Then the ThingOne folks update their code, so we want to incorporate
their changes into our version of their code. I think you're suggesting
that we might make a clone of the main repo then trigger a "git remote
update" in the clone's origin:
clone/$ make-origin-do-git-remote-update
What's not clear to me is how to proceed from here. At this point I'm
hoping there's some way I could do some work in the clone to merge the
changes the ThingOne folks did into our code. I'm too new to git to
know if there is a way forward -- is there?
(With the subtree merge pattern I'd run "git pull -s subtree ThingOne
master" in the main repo -- is there an equivalent achievable in the
clone if the main has done a "git remote update"?)
Thanks,
Marc
^ permalink raw reply
* Excluding files from git-diff
From: Erik Hahn @ 2008-10-17 14:53 UTC (permalink / raw)
To: git
I'm currently working on a script whose developer does not use
git. Hence, when I mail him the patch, I don't want to include the
.gitignore file. Is it possible to exclude a file from git-diff (except
not adding it to git, of course?)
-Erik
--
hackerkey://v4sw5hw2ln3pr5ck0ma2u7LwXm4l7Gi2e2t4b7Ken4/7a16s0r1p-5.62/-6.56g5OR
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-17 15:08 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Michael J Gruber, Peter Harris, git
In-Reply-To: <48F8A4E8.8070008@xiplink.com>
Marc Branchaud venit, vidit, dixit 17.10.2008 16:44:
> Thanks for joining the thread, Michael!
Sure, there's no need to mention it.
Well, maybe there is, given the recent discussion: Everyone can
contribute (with or without C/perl/whatever fu) and thus "pay back" for
free software, even by "only" trying to answer questions. But it
requires participation, combining efforts, rather than splitting off and
not returning... Uh, sorry, your question:
> Michael J Gruber wrote:
>> Would it be sufficient for you if a clone could trigger the main repo to
>> update its remotes (i.e. git remote update)?
>
> Hmmm, I'm not sure... How would the overall
> merge-in-changes-from-upstream process work in that case?
I thought your problem was "transporting" the remote branches from main
(which tracks external) to clone, without having the remote config for
external on the clones. In that case being able to trigger "remote
update" on main from the clones would help.
> Say the main repo has the code for "ThingOne" merged under a top-level
> thing-one/ directory:
>
> main/$ git remote add -f ThingOne git://thing/ThingOne.git
> main/$ git merge -s ours --no-commit ThingOne/master
> main/$ git read-tree --prefix=thing-one/ -i ThingOne/master
> main/$ git commit -m "Merged ThingOne into /thing-one/"
>
> Then the ThingOne folks update their code, so we want to incorporate
> their changes into our version of their code. I think you're suggesting
> that we might make a clone of the main repo then trigger a "git remote
> update" in the clone's origin:
>
> clone/$ make-origin-do-git-remote-update
>
> What's not clear to me is how to proceed from here. At this point I'm
> hoping there's some way I could do some work in the clone to merge the
> changes the ThingOne folks did into our code. I'm too new to git to
> know if there is a way forward -- is there?
>
> (With the subtree merge pattern I'd run "git pull -s subtree ThingOne
> master" in the main repo -- is there an equivalent achievable in the
> clone if the main has done a "git remote update"?)
"pull -s strategy repo master" does a fetch followed by "merge -s
strategy repomaster", where repomaster is the ref for master on repo.
So, if you got that branch (repomaster=ThingOne/master) by cloning from
main you can do the merge (subtree or other) on your clone, even without
the remote repo config for ThingOne on clone.
I guess you want to do those merges on several clones, and main, and
push everything back to main. I don't know how well that mixes, but I
don't expect problems, only unexpected ones ;)
Cheers,
Michael
^ permalink raw reply
* Re: Excluding files from git-diff
From: Raphael Zimmerer @ 2008-10-17 15:08 UTC (permalink / raw)
To: Erik Hahn; +Cc: git
In-Reply-To: <20081017145313.GA23471@eriks>
On Fri, Oct 17, 2008 at 04:53:13PM +0200, Erik Hahn wrote:
> I'm currently working on a script whose developer does not use
> git. Hence, when I mail him the patch, I don't want to include the
> .gitignore file. Is it possible to exclude a file from git-diff (except
> not adding it to git, of course?)
Just add the content of .gitignore to .git/info/exclude, and remove
.gitignore from the repository.
Raphael
^ permalink raw reply
* Re: Excluding files from git-diff
From: Johannes Schindelin @ 2008-10-17 15:08 UTC (permalink / raw)
To: Erik Hahn; +Cc: git
In-Reply-To: <20081017145313.GA23471@eriks>
Hi,
On Fri, 17 Oct 2008, Erik Hahn wrote:
> I'm currently working on a script whose developer does not use git.
> Hence, when I mail him the patch, I don't want to include the .gitignore
> file. Is it possible to exclude a file from git-diff (except not adding
> it to git, of course?)
You can specify everything else:
git diff -- *
Hth,
Dscho
^ permalink raw reply
* Re: Excluding files from git-diff
From: Michael J Gruber @ 2008-10-17 15:18 UTC (permalink / raw)
To: Erik Hahn; +Cc: git
In-Reply-To: <20081017145313.GA23471@eriks>
Erik Hahn venit, vidit, dixit 17.10.2008 16:53:
> I'm currently working on a script whose developer does not use
> git. Hence, when I mail him the patch, I don't want to include the
> .gitignore file. Is it possible to exclude a file from git-diff (except
> not adding it to git, of course?)
Am I right in assuming that by "script" you mean a manuscript consisting
of several files, rather than a single script (programme in scripting
language)? In any case:
git diff commit1 commit2 file
gives you the diff for "file" between those commits, so if you're really
interested in one file that's the way to go; you can also specify more
than one file here.
On the other hand, your .gitignore probably doesn't change that often,
so that it shouldn't show up in the diff after that anyways. Or put it
in .git/info/excludes.
Cheers,
Michael
^ 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