* Re: specify charset for commits
From: Uwe Kleine-König @ 2006-12-21 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, Johannes Schindelin, git
In-Reply-To: <7vejqtaz7q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Alexander Litvinov <litvinov2004@gmail.com> writes:
>
> > May we can add new header into commit with commit text encoding ?
>
> I do not think we want to change the commit header, nor we would
> want to re-encode, but I can see two possible improvements:
>
> (1) git-am should default to -u; this was suggested on the list
> long time ago, but is an incompatible change. v1.5.0 we
> can afford to be incompatible to make it more usable and
> safer.
>
> (2) update commit-tree to reject non utf-8 log messages and
> author/committer names when i18n.commitEncoding is _NOT_
> set, or set to utf-8.
>
> Maybe later we can use encoding validation routines for
> other encodings by checking i18n.commitEncoding, but at the
> minimum the above would be safe enough for recommended UTF-8
> only cases.
As I only want to use UTF-8 both suggestions are fine for me.
Is there a generic way to check an encoding? (I don't know if there is
an encoding that can encode everything. If so, we could use iconv -f
$enc -t superencoding. Until now I thought UTF-8 can do, but in the
post Johannes pointed out, you (Junio) implyed that it cannot.)
Best regards
Uwe
--
Uwe Kleine-König
dd if=/proc/self/exe bs=1 skip=1 count=3 2>/dev/null
^ permalink raw reply
* Re: specify charset for commits
From: Alexander Litvinov @ 2006-12-21 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Uwe Kleine-König, git
In-Reply-To: <7vejqtaz7q.fsf@assigned-by-dhcp.cox.net>
> I do not think we want to change the commit header
Can you please explain why not ?
> (1) git-am should default to -u; this was suggested on the list
> long time ago, but is an incompatible change. v1.5.0 we
> can afford to be incompatible to make it more usable and
> safer.
I use git-am rarely so can't comment on this
> (2) update commit-tree to reject non utf-8 log messages and
> author/committer names when i18n.commitEncoding is _NOT_
> set, or set to utf-8.
>
> Maybe later we can use encoding validation routines for
> other encodings by checking i18n.commitEncoding, but at the
> minimum the above would be safe enough for recommended UTF-8
> only cases.
See the situation:
1. I have utf-8 encoded repo.
2. Somebody clone my repo, try to commit using non-utf-8 encoding, fail and
change i18n.commitEncoding. When it commits something and ask me to pull.
3. I pull and got non-utf-8 commit message :-)
^ permalink raw reply
* Re: git-add,& "file vanishing" -> need git-add again
From: Martin Langhoff @ 2006-12-21 20:27 UTC (permalink / raw)
To: David Tweed; +Cc: git
In-Reply-To: <20061221141335.65170.qmail@web86902.mail.ukl.yahoo.com>
On 12/22/06, David Tweed <tweed314@yahoo.co.uk> wrote:
> Sidenote: I'm moving the database from the old format to the new one by repeatedly unpacking
> the old database for snapshot X, git-add'ing any file names which have _never_ been in any snapshot
> before, git-commit -a, git-tag, then remove all the files unpacked by the
> old database and move onto snapshot X+1. This takes less than a second per snapshot.
Not sure how large your snapshots are -- a second sounds like a long
time for git operations. While it is a bit more complex, you _can_
operate directly on the index, and the "snapshot" never needs to hit
the disk as such during your migration.
Have a look at how the cvsimport script works for an example.
cheers.
martin
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Juergen Ruehle @ 2006-12-21 20:35 UTC (permalink / raw)
To: Alex Riesen
Cc: Marco Roeland, Shawn Pearce, Linus Torvalds, Theodore Tso,
Nicolas Pitre, Johannes Schindelin, Randal L. Schwartz, git
In-Reply-To: <20061219202850.GA4501@steel.home>
Alex Riesen writes:
> Marco Roeland, Tue, Dec 19, 2006 10:13:19 +0100:
> > > Not that I personally frequently clone large projects on Mac OS X.
> > > But new users to Git might. :-)
> >
> > And perhaps the Cygwin version might benefit too.
>
> Does not work there at all. Even errno is not set (0).
Haven't seen a reply to this yet.
Upgrade cygwin.dll. The fix is pretty recent (1.5.22 or something).
Perhaps we now need a note in INSTALL.
Light testing seems to indicate that this change removes most of the
system times while leaving user time mostly unchanged (though I don't
know what cygwin time really reports in these categories). In the git
repository this is about 30% of the total time. For another (slightly
larger but with fewer objects) pack this still saves 20%. I haven't
compared it with the NO_MMAP version (too lazy), but overall it's a
win for cygwin as well (though we should note that cygwin's mmap seems
to have reasonable performance).
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Guennadi Liakhovetski @ 2006-12-21 20:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <4589F9B1.2020405@garzik.org>
On Wed, 20 Dec 2006, Jeff Garzik wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
Very nice, thanks! A couple of remarks from an absolute git newbie:
1. I heard "git am" is supposed to supersede apply-mbox
2. What I often have problems with is - what to do if git spits at me a
bunch of conflict messages after a seemingly safe pull or similar. Don't
know if you want to cover those points but "git troubleshooting" would
definitely be a valuable document.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Jeff Garzik @ 2006-12-21 20:46 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.60.0612212135230.5551@poirot.grange>
Guennadi Liakhovetski wrote:
> On Wed, 20 Dec 2006, Jeff Garzik wrote:
>
>> I refreshed my git intro/cookbook for kernel hackers, at
>> http://linux.yyz.us/git-howto.html
>
> Very nice, thanks! A couple of remarks from an absolute git newbie:
>
> 1. I heard "git am" is supposed to supersede apply-mbox
Hey, that's pretty neat. Glad you told me, this should improve my
workflow a bit.
> 2. What I often have problems with is - what to do if git spits at me a
> bunch of conflict messages after a seemingly safe pull or similar. Don't
> know if you want to cover those points but "git troubleshooting" would
> definitely be a valuable document.
Agreed.
Jeff
^ permalink raw reply
* Re: git-add,& "file vanishing" -> need git-add again
From: David Tweed @ 2006-12-21 20:47 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
Firstly, apologies for getting mail-list twice in original To: line: dunno how that happened.
|On 12/22/06, David Tweed <tweed314@yahoo.co.uk> wrote:
|> Sidenote: I'm moving the database from the old format to the new one by repeatedly unpacking
|> the old database for snapshot X, git-add'ing any file names which have _never_ been in any snapshot
|> before, git-commit -a, git-tag, then remove all the files unpacked by the
|> old database and move onto snapshot X+1. This takes less than a second per snapshot.
|
|Not sure how large your snapshots are -- a second sounds like a long
|time for git operations. While it is a bit more complex, you _can_
|operate directly on the index, and the "snapshot" never needs to hit
|the disk as such during your migration.
By trying to be brief I was a rather cryptic. What I was trying to say was:
Running the git commands
earlier in the message in a script, I see certain files are not present from the git tree generated by
a commit at a time when I know the file I'd previously git-added "reappears" in the
working directory. I'm hypothesising that this is because when the file disappears the machinery
in git discards the `track this file name' information. However, I haven't (and would prefer not to)
dig into the git code to check that's the correct explanation. If this is why the files aren't
being tracked I can try to script around the issue by git-adding all the files I want tracked
by the snapshot before the git-commit -a. To help anyone thinking
about if the explanation is right, the working directory is repeatedly being wiped and refilled from my old
backup system with a second, so often all files have both creation and modification times
set to the current second regardless of whether the content has changed. This is a really
weird thing to do and might in some way be responsible for the untracked file (cf racy-git).
Most of the maybe half-second overhead is coming from my script unpacking the files with gzip
from my old database; git seems more than fast enough.
|Have a look at how the cvsimport script works for an example.
As it's my personal db which I'll only convert once if I can just make replaying work
I don't need anything more complicated; I've only got 2000-odd snapshots of 2500-odd files.
However, the temporarily disappearing file issue is one I think I'll face with any
cron-based commiting strategy and so need to solve.
cheers, dave tweed
___________________________________________________________
Yahoo! Photos – NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Nigel Cunningham @ 2006-12-21 21:17 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <458A73A6.4010805@garzik.org>
Hi.
On Thu, 2006-12-21 at 06:44 -0500, Jeff Garzik wrote:
> Nigel Cunningham wrote:
> > Hi.
> >
> > On Wed, 2006-12-20 at 22:04 -0500, Jeff Garzik wrote:
> >> I refreshed my git intro/cookbook for kernel hackers, at
> >> http://linux.yyz.us/git-howto.html
> >>
> >> This describes most of the commands I use in day-to-day kernel hacking.
> >> Let me know if there are glaring errors or missing key commands.
> >
> > Thanks for the work! I'd suggest also saying how to repack and cleanup.
>
> Yes, I should mention repacking. When you say cleanup, what
> specifically do you mean?
Oh, I was just thinking of the related commands - prune-packed,
count-objects, fsck-objects and so on. (I know repack does prune-packed
when you use -d, but it might be handy to mention it anyway... or
not :>)
> > Could also be a good idea to go through the steps for uploading to
> > master.kernel.org or elsewhere?
>
> Yes, push should be mentioned at the very least.
Nigel
^ permalink raw reply
* confusion over the new branch and merge config
From: Nicolas Pitre @ 2006-12-21 22:17 UTC (permalink / raw)
To: git
OK I know I'm a total idiot and honnestly I didn't look at the code
implementation at all because I don't expect newbies to even look there.
But here's some pitfalls I'm sure people are likely to encounter...
$ git clone git://git.kernel.org/pub/scm/git/git.git git
Initialized empty Git repository in /home/nico/test/git/.git/
remote: Generating pack...
remote: Done counting 34527 objects.
remote: Deltifying 34527 objects.
remote: 100% (34527/34527) done
Indexing 34527 objects.
remote: Total 34527, written 34527 (delta 23920), reused 34111 (delta 23623)
100% (34527/34527) done
Resolving 23920 deltas.
100% (23920/23920) done
Checking files out...
100% (748/748) done
[ wooh! I feel good ]
$ cd git
$ git branch
* master
[ Hmmm... there used to be many more (remote) branches before. Where
are they? Looking into .git/refs I see a remote/ directory and all
remote branches are there. But I'm cheating now because a newbie
might not even think of looking there.
Ah? there is -a and -r options to git-branch. Fair enough. ]
$ git branch -r
* master
origin/HEAD
origin/html
origin/maint
origin/man
origin/master
origin/next
origin/pu
origin/todo
$ git checkout next
error: pathspec 'next' did not match any file(s) known to git.
Did you forget to 'git add'?
[ WTF!?!? This definitely used to work before. OK it is listed as
"origin/next" so let's try to be consistent. ]
$ git checkout origin/next
git checkout: to checkout the requested commit you need to specify
a name for a new branch which is created and switched to
[ Hmmmmmmmm.... /me stares at the message wondering.
I just want to _see_ and maybe _install_ the code from "next". ]
$ git checkout origin/next local_next
error: pathspec 'local_next' did not match any file(s) known to git.
Did you forget to 'git add'?
[ But it just said to me above that I needed to provide a name for the
branch to be switched to... Why doesn't it just work? F***ing tool!
OK I'll use my git knowledge and cheat again. ]
$ git checkout -b local_next origin/next
This is I think a good example where user experience might still be
improved. First the message about "providing a name for a new branch"
could certainly be less anbigous.
Then the "next" branch name could possibly be made to work without the
"origin/" if there is no conflict?
And there was a discussion about allowing checkouts to be made from a
remote branch but not allowing any commit on it. What happened of this
idea?
Now that I have my local_next branch, I want it to be kept up to date
when performing a pull. Before the "next" branch sort of was always
updated, but now it is a separate thing I cannot see directly and I need
to pull it in my local version.
$ git pull origin/next
fatal: The remote end hung up unexpectedly
Cannot get the repository state from git://git.kernel.org/pub/scm/git/git.git/next
[ WTF? Where that ...pub/scm/git/git.git/next comes from? Hmmm... ]
$ git pull next
fatal: 'next': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
Cannot get the repository state from next
[ ... an even more interesting set of error messages.
Yeah, Linus says you must use git-pull . blah syntax. ]
$ git pull . next
error: no such remote ref refs/heads/next
Fetch failure: .
$ git pull . origin/next
error: no such remote ref refs/heads/origin/next
Fetch failure: .
[ F**K YOU STUPID TOOL !!! OK let's cheat a bit again. ]
$ git pull . remotes/origin/next
Already up-to-date.
[ Woooh! But since I always hated this syntax let's try merge instead. ]
$ git merge origin/next
Already up-to-date.
OK here again various error messages could be improved. The fact that a
remote connection was established in some cases is really dubious. And
git-pull not accepting "origin/next" is IMHO a bug.
Well well... But I don't want to perform this two-step
git-pull+git-merge all the time. So let's have a look at this promising
warning:
$ git pull origin
Warning: No merge candidate found because value of config option
"branch.local_next.merge" does not match any remote branch fetched.
No changes.
So this means that branch.local_next.merge should be set to origin/next?
Let's have a look at the default in .git/config:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
But according to the warning above, branch.master.merge should have been
set to refs/remotes/origin/master, not refs/heads/master, right?
Otherwise does this mean that master will merge itself into itself?
This is where my own git experience stops as I don't understand the
above for real. So let's see the doc:
|branch.<name>.merge::
| When in branch <name>, it tells `git fetch` the default refspec to
| be marked for merging in FETCH_HEAD. The value has exactly to match
| a remote part of one of the refspecs which are fetched from the remote
| given by "branch.<name>.remote".
| The merge information is used by `git pull` (which at first calls
| `git fetch`) to lookup the default branch for merging. Without
| this option, `git pull` defaults to merge the first refspec fetched.
| Specify multiple values to get an octopus merge.
Hmmmmmmm... Even after reading this twice I'm still not sure what it
really means. But as I said at the top I'm an idiot.
Nicolas
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Junio C Hamano @ 2006-12-21 23:01 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612211555210.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> [ Hmmm... there used to be many more (remote) branches before. Where
> are they? Looking into .git/refs I see a remote/ directory and all
> remote branches are there. But I'm cheating now because a newbie
> might not even think of looking there.
>
> Ah? there is -a and -r options to git-branch. Fair enough. ]
A newbie might not even expect to see "many more branches"
because there is no "before" for him.
> $ git checkout origin/next
> git checkout: to checkout the requested commit you need to specify
> a name for a new branch which is created and switched to
>
> [ Hmmmmmmmm.... /me stares at the message wondering.
> I just want to _see_ and maybe _install_ the code from "next". ]
Rewording to suggest "checkout -b newbranchname origin/next", perhaps?
> $ git checkout -b local_next origin/next
"git checkout -b next origin/next" should work just fine, I
think.
There was a talk about allowing "checkout -b <new> <track>" to
add branch.<new>.merge and branch.<new>.remote if <track> can be
proven to corresond uniquely to one remote and one branch from
that remote; I think that would match the expectation most of
the time but that "most" would not be 100% nor even 80%, so I
think that should be an optional feature. In any case, there
was a talk but there is no code yet.
> And there was a discussion about allowing checkouts to be made from a
> remote branch but not allowing any commit on it. What happened of this
> idea?
It remains to be an idle talk without any code. Contributions
appreciated.
> $ git pull origin/next
> fatal: The remote end hung up unexpectedly
> Cannot get the repository state from git://git.kernel.org/pub/scm/git/git.git/next
>
> [ WTF? Where that ...pub/scm/git/git.git/next comes from? Hmmm... ]
This comes from ancient request by Linus to allow:
$ cat .git/remotes/jgarzik
URL: master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/
$ git pull jgarzik/misc-2.6
See http://article.gmane.org/gmane.comp.version-control.git/6181
for the full text.
Personally I thought this was confusing when I implemented it
the first time, and I still find it confusing.
I suspect nobody uses it. I am all for removing this "URL
prefix shorthand" feature in v1.5.0.
> $ git pull . remotes/origin/next
> Already up-to-date.
>
> [ Woooh! But since I always hated this syntax let's try merge instead. ]
>
> $ git merge origin/next
> Already up-to-date.
Yes, that is one of the reasons that you would prefer 'merge'
when you are working locally.
> $ git pull origin
> Warning: No merge candidate found because value of config option
> "branch.local_next.merge" does not match any remote branch fetched.
> No changes.
>
> So this means that branch.local_next.merge should be set to origin/next?
No, the message says "any REMOTE branch" -- refs/heads/next is
what it is called at the remote, and that is how the value is
expected to be spelled; I think somebody added an example to
config.txt recently to stress this. The above error messasge
obviously was not clear enough. Rewording appreciated.
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Sean @ 2006-12-21 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vd56cam66.fsf@assigned-by-dhcp.cox.net>
On Thu, 21 Dec 2006 15:01:21 -0800
Junio C Hamano <junkio@cox.net> wrote:
> No, the message says "any REMOTE branch" -- refs/heads/next is
> what it is called at the remote, and that is how the value is
> expected to be spelled; I think somebody added an example to
> config.txt recently to stress this. The above error messasge
> obviously was not clear enough. Rewording appreciated.
This seems inconsistent and confusing. When working with the
local repository, git-branch doesn't list that as "refs/heads/next"
it just lists "next". Why all of a sudden when trying to fetch
it from a remote repo must a user know about "refs/heads"?
This seems like an internal detail slipping into the user interface.
But maybe i'm wrong, when would it ever be anything other than
"refs/heads/<branch>"? If it's _always_ "refs/heads", couldn't that
prefix just be assumed if not provided by the user?
Sean
^ permalink raw reply
* Re: t5000-tar-tree.sh failing
From: Brian Gernhardt @ 2006-12-21 23:37 UTC (permalink / raw)
To: Uwe Kleine-Koenig; +Cc: Johannes Schindelin, git
In-Reply-To: <20061221185948.GA27072@informatik.uni-freiburg.de>
On Dec 21, 2006, at 1:59 PM, Uwe Kleine-Koenig wrote:
> I'm not sure if (in this case) a missing unzip should be as silent as
> you suggest. The danger is, that s.o. makes a change, runs `make
> test`
> and is then conviced that nothing broke. So I think that the test
> should fail, but with a more descriptive error than it is now.
>
> The downside is, you need unzip, svn, what ever more to run the test
> suite.
I was attempting to say that if we're skipping tests we should say
so, and not just drop them silently like the code that Johannes
posted. Really, I guess the ideal would be for there to be a test
harness that would run all the tests and report skips and errors in a
report at the end rather than in the middle.
~~ Brian
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Jakub Narebski @ 2006-12-21 23:48 UTC (permalink / raw)
To: git
In-Reply-To: <b0943d9e0612131414h25a75bf8h14b5a1731ea47afb@mail.gmail.com>
Catalin Marinas wrote:
> I'll try to add a wiki page with todo/wishlist ideas and prioritise
> those included before 1.0. Post 1.0, I'll try to look at changing the
> repository layout a bit to reduce the amount of metadata and also
> facilitate the support for transactions etc.
What about this page? Not found on
http://wiki.procode.org/cgi-bin/wiki.cgi?action=index
By the way, it would be nice to be able to put in cover mail template the
following variables:
* %(patches)s - list of patch names, each in one line, '* ' prefixed
* %(patchesdescr)s - list of patch %(shortdescr)s, the first line
of the patch description, shortlog-like word-wrapped, perhaps with,
perhaps without [PATCH m/n] prefix.
* %(diffstat) - diff statistics of first and last patch, only if
there are no gaps in patches provided nor patch reordering
(single patch, single range, or -a)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: warning merge message
From: Luben Tuikov @ 2006-12-22 0:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612211022280.19693@wbgn013.biozentrum.uni-wuerzburg.de>
--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Can we please eliminate this f@#$ing message:
> > Warning: No merge candidate found because value of config option
> > "branch.master.merge" does not match any remote branch fetched.
>
> Well, you can always tell git explicitely what you want. I.e. specify the
> remote _and_ the branch you want to merge.
What would be that setting if I want the default behavior?
Is this "merge candidate let-me-impose-my-workflow-on-you" merge
a single step or does it also checkout as
the default behavior: fast forward local origin to remote master,
merge local origin to local master, check out master?
> BTW I am still waiting for your test results regarding the segmentation
> fault of merge-recursive.
I'm swamped. Did you say you have no 64 bit machines you can try it on?
Also, I don't mind giving you my dev tree, but currently I don't export
it anywhere. BTW, I've seen this bug on 64 bit machines. I've not tried
it on 32.
Luben
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Junio C Hamano @ 2006-12-22 0:39 UTC (permalink / raw)
To: Sean; +Cc: Nicolas Pitre, git
In-Reply-To: <20061221182102.906ad046.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes the value of
branch.<me>.merge being the name at the remote site, saying:
> This seems inconsistent and confusing.
Check the archive for messages on this issue that talks about
the case without tracking branches.
^ permalink raw reply
* Re: warning merge message
From: Shawn Pearce @ 2006-12-22 0:43 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Johannes Schindelin, git
In-Reply-To: <121430.93915.qm@web31808.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> wrote:
> I'm swamped. Did you say you have no 64 bit machines you can try it on?
> Also, I don't mind giving you my dev tree, but currently I don't export
> it anywhere. BTW, I've seen this bug on 64 bit machines. I've not tried
> it on 32.
I have an amd64 here that I need to finish configuring. Its running
well enough however that I could debug this issue on that machine
if I could get the branches in question.
merge-recursive and the xdl_merge() routine aren't exactly my area
of expertise, but if Johannes can't do it I'll step up and see what
I can do.
--
Shawn.
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Junio C Hamano @ 2006-12-22 0:46 UTC (permalink / raw)
To: Sean; +Cc: Nicolas Pitre, git
In-Reply-To: <20061221182102.906ad046.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> This seems inconsistent and confusing. When working with the
> local repository, git-branch doesn't list that as "refs/heads/next"
> it just lists "next". Why all of a sudden when trying to fetch
> it from a remote repo must a user know about "refs/heads"?
You can always say "git log refs/heads/next" even though you are
allowed to say "git log next". Maybe we should remove that
shorthand to make it consistent? I think not.
The remote side can add things without your knowing, so
insisting on the exact match makes sense in a weird sort of
way.
And this is a config file you would set once and then can forget
about it. I do not see a big deal about having to spell it
fully.
^ permalink raw reply
* [PATCH 1/3] Rename imap-send's internal info/warn functions.
From: Shawn O. Pearce @ 2006-12-22 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Because I am about to introduce a global warn() function (much
like the global error function) this global declaration would
conflict with the one supplied by imap-send. Further since
imap-send's warn function output depends on its Quiet setting
we cannot simply remove its internal definition and use the
forthcoming global one.
So refactor warn() -> imap_warn() and info() -> imap_info()
(the latter was done just to be consistent in naming).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
imap-send.c | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 894cbbd..ad91858 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -96,8 +96,8 @@ typedef struct {
static int Verbose, Quiet;
-static void info( const char *, ... );
-static void warn( const char *, ... );
+static void imap_info( const char *, ... );
+static void imap_warn( const char *, ... );
static char *next_arg( char ** );
@@ -297,7 +297,7 @@ buffer_gets( buffer_t * b, char **s )
}
static void
-info( const char *msg, ... )
+imap_info( const char *msg, ... )
{
va_list va;
@@ -310,7 +310,7 @@ info( const char *msg, ... )
}
static void
-warn( const char *msg, ... )
+imap_warn( const char *msg, ... )
{
va_list va;
@@ -903,7 +903,7 @@ imap_open_store( imap_server_conf_t *srvc )
/* open connection to IMAP server */
if (srvc->tunnel) {
- info( "Starting tunnel '%s'... ", srvc->tunnel );
+ imap_info( "Starting tunnel '%s'... ", srvc->tunnel );
if (socketpair( PF_UNIX, SOCK_STREAM, 0, a )) {
perror( "socketpair" );
@@ -926,31 +926,31 @@ imap_open_store( imap_server_conf_t *srvc )
imap->buf.sock.fd = a[1];
- info( "ok\n" );
+ imap_info( "ok\n" );
} else {
memset( &addr, 0, sizeof(addr) );
addr.sin_port = htons( srvc->port );
addr.sin_family = AF_INET;
- info( "Resolving %s... ", srvc->host );
+ imap_info( "Resolving %s... ", srvc->host );
he = gethostbyname( srvc->host );
if (!he) {
perror( "gethostbyname" );
goto bail;
}
- info( "ok\n" );
+ imap_info( "ok\n" );
addr.sin_addr.s_addr = *((int *) he->h_addr_list[0]);
s = socket( PF_INET, SOCK_STREAM, 0 );
- info( "Connecting to %s:%hu... ", inet_ntoa( addr.sin_addr ), ntohs( addr.sin_port ) );
+ imap_info( "Connecting to %s:%hu... ", inet_ntoa( addr.sin_addr ), ntohs( addr.sin_port ) );
if (connect( s, (struct sockaddr *)&addr, sizeof(addr) )) {
close( s );
perror( "connect" );
goto bail;
}
- info( "ok\n" );
+ imap_info( "ok\n" );
imap->buf.sock.fd = s;
@@ -979,7 +979,7 @@ imap_open_store( imap_server_conf_t *srvc )
if (!preauth) {
- info ("Logging in...\n");
+ imap_info ("Logging in...\n");
if (!srvc->user) {
fprintf( stderr, "Skipping server %s, no user\n", srvc->host );
goto bail;
@@ -1006,7 +1006,7 @@ imap_open_store( imap_server_conf_t *srvc )
fprintf( stderr, "Skipping account %s@%s, server forbids LOGIN\n", srvc->user, srvc->host );
goto bail;
}
- warn( "*** IMAP Warning *** Password is being sent in the clear\n" );
+ imap_warn( "*** IMAP Warning *** Password is being sent in the clear\n" );
if (imap_exec( ctx, NULL, "LOGIN \"%s\" \"%s\"", srvc->user, srvc->pass ) != RESP_OK) {
fprintf( stderr, "IMAP error: LOGIN failed\n" );
goto bail;
--
1.4.4.3.ga78a1
^ permalink raw reply related
* [PATCH 2/3] Introduce a global level warn() function.
From: Shawn O. Pearce @ 2006-12-22 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <be6b1443171482e1930bd7744a0218db0c03d611.1166748450.git.spearce@spearce.org>
Like the existing error() function the new warn() function can be
used to describe a situation that probably should not be occuring,
but which the user (and Git) can continue to work around without
running into too many problems.
An example situation is a bad commit SHA1 found in a reflog.
Attempting to read this record out of the reflog isn't really an
error as we have skipped over it in the past.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-compat-util.h | 2 ++
usage.c | 19 +++++++++++++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 41fa7f6..304cdbf 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -71,10 +71,12 @@
extern void usage(const char *err) NORETURN;
extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
+extern void warn(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern void set_usage_routine(void (*routine)(const char *err) NORETURN);
extern void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN);
extern void set_error_routine(void (*routine)(const char *err, va_list params));
+extern void set_warn_routine(void (*routine)(const char *warn, va_list params));
#ifdef NO_MMAP
diff --git a/usage.c b/usage.c
index 52c2e96..4dc5c77 100644
--- a/usage.c
+++ b/usage.c
@@ -29,12 +29,17 @@ static void error_builtin(const char *err, va_list params)
report("error: ", err, params);
}
+static void warn_builtin(const char *warn, va_list params)
+{
+ report("warning: ", warn, params);
+}
/* If we are in a dlopen()ed .so write to a global variable would segfault
* (ugh), so keep things static. */
static void (*usage_routine)(const char *err) NORETURN = usage_builtin;
static void (*die_routine)(const char *err, va_list params) NORETURN = die_builtin;
static void (*error_routine)(const char *err, va_list params) = error_builtin;
+static void (*warn_routine)(const char *err, va_list params) = warn_builtin;
void set_usage_routine(void (*routine)(const char *err) NORETURN)
{
@@ -51,6 +56,11 @@ void set_error_routine(void (*routine)(const char *err, va_list params))
error_routine = routine;
}
+void set_warn_routine(void (*routine)(const char *warn, va_list params))
+{
+ warn_routine = routine;
+}
+
void usage(const char *err)
{
@@ -75,3 +85,12 @@ int error(const char *err, ...)
va_end(params);
return -1;
}
+
+void warn(const char *warn, ...)
+{
+ va_list params;
+
+ va_start(params, warn);
+ warn_routine(warn, params);
+ va_end(params);
+}
--
1.4.4.3.ga78a1
^ permalink raw reply related
* [PATCH 3/3] Don't crash during repack of a reflog with pruned commits.
From: Shawn O. Pearce @ 2006-12-22 0:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <be6b1443171482e1930bd7744a0218db0c03d611.1166748450.git.spearce@spearce.org>
If the user has been using reflog for a long time (e.g. since its
introduction) then it is very likely that an existing branch's
reflog may still mention commits which have long since been pruned
out of the repository.
Rather than aborting with a very useless error message during
git-repack, pack as many valid commits as we can get from the
reflog and let the user know that the branch's reflog contains
already pruned commits. A future 'git reflog expire' (or whatever
it finally winds up being called) can then be performed to expunge
those reflog entries.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
revision.c | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/revision.c b/revision.c
index de2cbd8..52330cc 100644
--- a/revision.c
+++ b/revision.c
@@ -466,6 +466,7 @@ static void limit_list(struct rev_info *revs)
struct all_refs_cb {
int all_flags;
+ int warned_bad_reflog;
struct rev_info *all_revs;
const char *name_for_errormsg;
};
@@ -487,25 +488,33 @@ static void handle_all(struct rev_info *revs, unsigned flags)
for_each_ref(handle_one_ref, &cb);
}
-static int handle_one_reflog_ent(unsigned char *osha1, unsigned char *nsha1, char *detail, void *cb_data)
+static int handle_one_reflog_commit(unsigned char *sha1, void *cb_data)
{
struct all_refs_cb *cb = cb_data;
- struct object *object;
-
- if (!is_null_sha1(osha1)) {
- object = get_reference(cb->all_revs, cb->name_for_errormsg,
- osha1, cb->all_flags);
- add_pending_object(cb->all_revs, object, "");
+ if (!is_null_sha1(sha1)) {
+ struct object *o = parse_object(sha1);
+ if (o) {
+ o->flags |= cb->all_flags;
+ add_pending_object(cb->all_revs, o, "");
+ } else if (!cb->warned_bad_reflog) {
+ warn("reflog of '%s' references pruned commits",
+ cb->name_for_errormsg);
+ cb->warned_bad_reflog = 1;
+ }
}
- object = get_reference(cb->all_revs, cb->name_for_errormsg,
- nsha1, cb->all_flags);
- add_pending_object(cb->all_revs, object, "");
+}
+
+static int handle_one_reflog_ent(unsigned char *osha1, unsigned char *nsha1, char *detail, void *cb_data)
+{
+ handle_one_reflog_commit(osha1, cb_data);
+ handle_one_reflog_commit(nsha1, cb_data);
return 0;
}
static int handle_one_reflog(const char *path, const unsigned char *sha1, int flag, void *cb_data)
{
struct all_refs_cb *cb = cb_data;
+ cb->warned_bad_reflog = 0;
cb->name_for_errormsg = path;
for_each_reflog_ent(path, handle_one_reflog_ent, cb_data);
return 0;
--
1.4.4.3.ga78a1
^ permalink raw reply related
* Re: warning merge message
From: Junio C Hamano @ 2006-12-22 0:49 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <867728.44872.qm@web31814.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Can we please eliminate this message:
> Warning: No merge candidate found because value of config option
> "branch.master.merge" does not match any remote branch fetched.
The above message was meant only for "git pull", but was leaked
even when you did "git fetch"; it was a bug and was corrected
already (hopefully).
^ permalink raw reply
* Re: [PATCH 3/3] Don't crash during repack of a reflog with pruned commits.
From: Junio C Hamano @ 2006-12-22 0:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061222004906.GC14789@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> If the user has been using reflog for a long time (e.g. since its
> introduction) then it is very likely that an existing branch's
> reflog may still mention commits which have long since been pruned
> out of the repository.
I've thought about this issue when I did the repack/prune; my
take on this was you should prune reflog first then repack.
^ permalink raw reply
* Re: [PATCH] fix vc git
From: Junio C Hamano @ 2006-12-22 0:52 UTC (permalink / raw)
To: Duncan Mak; +Cc: git
In-Reply-To: <8e745ecf0612210359j3f895521r1fff497a512253d3@mail.gmail.com>
"Duncan Mak" <duncan@a-chinaman.com> writes:
> --- a/contrib/emacs/vc-git.el
> +++ b/contrib/emacs/vc-git.el
> @@ -58,7 +58,7 @@
> (with-temp-buffer
> (let* ((dir (file-name-directory file))
> (name (file-relative-name file dir)))
> - (when dir (cd dir))
> + (when (file-exists-p dir) (cd dir))
> (and (ignore-errors (eq 0 (call-process "git" nil '(t nil) nil
> "ls-files" "-c" "-z" "--" name)))
> (let ((str (buffer-string)))
> (and (> (length str) (length name))
I wonder what would happen when (file-name-directory file)
returns nil with this change...
^ permalink raw reply
* Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting
From: Junio C Hamano @ 2006-12-22 0:52 UTC (permalink / raw)
To: Marco Roeland
Cc: Terje Sten Bjerkseth, Randal L. Schwartz, Junio C Hamano,
Linus Torvalds, Rocco Rutte, git
In-Reply-To: <20061221112835.GA7713@fiberbit.xs4all.nl>
Marco Roeland <marco.roeland@xs4all.nl> writes:
> We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!
Personally, I think hiding interfaces such as strXXX and memXXX
based on _XOPEN_SOURCE level is already a bug in the system
header implementation. The symbols that begin with str are
already reserved by the standard and I do not see any point
in the system headers to try avoiding namespace contamination.
But we are not in the business of fixing the system headers.
> The preferred way of checking specific Apple specific issues is by using
> the __APPLE__ predefined macro.
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index bc296b3..6f46f36 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -11,7 +11,14 @@
>
> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>
> +#if !defined(__APPLE__) && !defined(__FreeBSD)
> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
> +#else
> + /*
> + * On Darwin and FreeBSD defining _XOPEN_SOURCE always restricts available
> + * functions and symbols.
> + */
> +#endif
> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
> #define _GNU_SOURCE
> #define _BSD_SOURCE
Two and half questions.
#0.5 Have you checked the tip of 'master' that has Terje's
patch? It was reported to work yesterday and that is what
was committed already.
#1 __APPLE__ vs __APPLE_CC__ is not something I can decide (I
do not run a Mac). If MaxOS is derived from FreeBSD, does
it by chance define __FreeBSD as well?
#2 Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a
Mac, but yours doesn't. Is there a reason that you would
want '#define _XOPEN_SOURCE_EXTENDED 1'? Do both FreeBSD
and Mac behave well with it defined?
^ permalink raw reply
* Re: GIT - error: no such remote ref refs/heads/TestBranch
From: Junio C Hamano @ 2006-12-22 0:52 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <slrneokplo.nsf.Peter.B.Baumann@xp.machine.xx>
Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
writes:
> I'm also not so confident about mixing "add NEW files" with "updating
> the contents of already known files".
File boundaries do not matter ;-) You are adding contents.
Sometimes new contents are contained in a file that git already
knew about. Other times they are contained in a file that git
did not know about.
But that is a phylosophical answer, not a practical one, since
majority of the time (unless you are talking about the first few
weeks of a new project) you will be adding contents that happen
to be in the files git knows about.
I think the operation related but different from "git add ."
Carl talks about would be useful in practice. I do not know
what the option should be called.
"git add --modified"?
"git add --tracked"?
"git add --updated"?
It would work in the same way as the pre-commit step of "git
commit -a".
^ 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