* Re: git (commit|tag) atomicity
From: Jakub Narebski @ 2012-02-28 17:41 UTC (permalink / raw)
To: Jon Jagger; +Cc: git, Holger Hellmuth
In-Reply-To: <CADWOt=ig5=Bhhkjs9-wbm2djtwWPOfPGtYt9pH-U3YuQ+iyXzg@mail.gmail.com>
Jon Jagger <jon@jaggersoft.com> writes:
> On Tue, Feb 28, 2012 at 4:46 PM, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> > On 28.02.2012 16:40, Jon Jagger wrote:
>>>
>>> I don't know a lot about git - I use it as a tool behind
>>> http://cyber-dojo.com
>>> which is an online coding dojo server.
>>> I have a quick question...
>>> If I do a
>>> git commit ....
>>> in one thread and a
>>> git tag | sort -g
>>> in another thread is the output of the git tag guaranteed to be atomic?
>>
>> Can a "git commit" add or remove tags? AFAIK it can't and so the two
>> commands don't conflict in any way.
>
> Sorry, I failed to ask the question I really wanted to ask...
>
> I mean in one thread
> git tag -m 'AAA' BBB HEAD
> and in another thread
> git tag | sort -g
>
> and the question is whether the output of the git tag|sort -g command
> is guaranteed to be from before the git tag -m... or from after the
> git tag -m... but not "interleaved" in any way....
Creating a tag or a commit is guaranteed to be atomic. Git first
atomically adds tag or a commit to object database (atomic file write)
as loose object, then atomically writes tag reference as loose tag
('.git/refs/tags/foo' file, containing SHA-1 id of newly created tag).
"git tag", which list all tags, recursively scans (reads) 'refs/tags/'
directory, so it could theoretically happen that if you have very
large number of loose (unpacked) tags, "git tag" might theoretically
list tag 'zzz' created after start of command, but not list 'aaa' tag
created after start of command.
But I am not sure... that probably depends on how opendir(3) and
readdir(3) works on given filesystem wrt. updates to opened directory.
I think VFS on Linux ensures that you see view of filesystem as it was
on opendir().
--
Jakub Narebski
^ permalink raw reply
* l10n: the maintaince of git-po repo
From: Jiang Xin @ 2012-02-28 17:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
I'm looking forward to the next git release with Chinese l10n, so that
I can start to rewrite my book on Git. ;-)
The maintaince of the git-po and git-po-zh_CN repositories so far:
git-po repository
-----------------
Location : https://github.com/gotgit/git-po
Fork from : https://github.com/git/git
Description: This is the Git l10n master repo, and is used to coordinate
works of l10n teams. L10n team leaders send pull requests
to this repo, while other l10n contributors should wok on
the language specified repository created by the l10n team
leader.
Typical commits:
- commit https://github.com/gotgit/git-po/commit/71eb878
merge the pull request sent from the Chinese l10n team leader.
- commit https://github.com/gotgit/git-po/commit/1d4ac88
l10n: Update git.pot (12 new messages)
- commit https://github.com/gotgit/git-po/commit/508d124
Merge branch 'master' of 'git.git' into git-po,
and will generate new po/git.pot in next commit.
- commit https://github.com/gotgit/git-po/commit/dce37b6
l10n: initial git.pot for 1.7.10 upcoming release
git-po-zh_CN repository
-----------------------
Location : https://github.com/jiangxin/git-po-zh_CN
Fork from : https://github.com/gotgit/git-po
Description: Git l10n for Simplified Chinese.
Typical commits:
- commit https://github.com/jiangxin/git-po-zh_CN/commit/7ac1c0a
l10n: update Chinese translation to the new git.po
- commit https://github.com/jiangxin/git-po-zh_CN/commit/0ad9e96
fix of Chinese translation
- commit https://github.com/jiangxin/git-po-zh_CN/commit/d4a8e00
fix of Chinese translation
- commit https://github.com/jiangxin/git-po-zh_CN/commit/c04f5ac
l10n: initial of zh_CN l10n
--
Jiang Xin
^ permalink raw reply
* Re: [PATCH] branch: don't assume the merge filter ref exists
From: Junio C Hamano @ 2012-02-28 17:32 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Jeff King, Bernhard Reutner-Fischer, git
In-Reply-To: <1330442090.691.9.camel@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> On Mon, 2012-02-27 at 14:43 -0500, Jeff King wrote:
>>
>> It looks like "bad object" generally comes from parse_object failing,
>> which makes sense. It either means object corruption or you fed a full
>> 40-char sha1 that didn't exist (which, if you are being that specific,
>> probably is an indication of broken-ness in your repository).
>
> Right. Another version of the fix I was playing with used parse_object
> after get_sha1 in opt_parse_merge_filter to make sure there that the
> objects did exist, so I copied that error message for this patch.
>
> I see Junio's already squashed this in, and it's certainly a better
> message.
Ok, so what I have is good for everybody. Will merge to "next" and soon
to "master" and "maint".
Thanks, both.
^ permalink raw reply
* Re: [PATCH 1/3] http: authenticate on NTLM proxies and others suppported, by CuRL
From: Thomas Rast @ 2012-02-28 17:30 UTC (permalink / raw)
To: Nelson Benitez Leon; +Cc: git, peff, sam, sam.vilain
In-Reply-To: <4F4D19CC.5030303@seap.minhap.es>
Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> On 02/28/2012 03:32 PM, Thomas Rast wrote:
>> Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
>>
>>> - if (curl_http_proxy)
>>> + if (curl_http_proxy) {
>>> curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>>> + curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
>>> + }
>>
>> There was another attempt at doing the same very recently:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/191140
>>
>> I could swear there was a second one, but apparently that was you.
>> Neither you nor Marco submitter have so far answered the question I
>> raised in
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/191155
>>
>> which can be summarized as: please make a case -- and put it in the
>> message! -- for or against making this configurable. Is there a speed
>> tradeoff? (However, you could steal some of Daniel Stenberg's
>> reasoning!)
>
> I don't see any reason to make this configurable, [snip]
Sorry for not making this clear, but you don't have to explain it to me
in the list archives; rather, the commit message should sufficiently
take care of it. That is, I was objecting to your (lack of a) commit
message.
The argument you need to counter here is (Daniel explains this) curl
does an extra roundtrip to the proxy to determine which protocols work,
which is a little extra cost.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC PATCH 2a] pretty: detect missing \n\n in commit message
From: Junio C Hamano @ 2012-02-28 17:27 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, git
In-Reply-To: <5234ba4babd28d9430750d227d629b4d4386b131.1330425111.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> get_header()'s exit condition is finding the \n\n that separates the
> commit header from its message. If such a double newline is not
> present, it segfaults. Catch this case and die().
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> This would be the minimal fix to the pretty machinery so that 'git
> rev-list --pretty=something HEAD' works when there are such broken
> commits.
>
> If 2b goes in, there isn't really any point as we would never get this
> far on such a commit.
>
>
> pretty.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/pretty.c b/pretty.c
> index 8688b8f..b7f097d 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -440,7 +440,10 @@ static char *get_header(const struct commit *commit, const char *key)
> const char *line = commit->buffer;
>
> for (;;) {
> - const char *eol = strchr(line, '\n'), *next;
> + const char *eol, *next;
> + if (!line)
> + die (_("malformed commit object: no separating \\n\\n?"));
> + eol = strchr(line, '\n');
The same comment applies here.
You can just return NULL in this case, I suppose?
> if (line == eol)
> return NULL;
^ permalink raw reply
* Re: [PATCH v2] commit: allow {--amend|-c foo} when {HEAD|foo} has empty message
From: Junio C Hamano @ 2012-02-28 17:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, git
In-Reply-To: <010901fbfffe0f806bb19d556ebc1e512a4697f4.1330425111.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 3714582..5e9a832 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -690,7 +690,9 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
> hook_arg1 = "message";
> } else if (use_message) {
> buffer = strstr(use_message_buffer, "\n\n");
> - if (!buffer || buffer[2] == '\0')
> + if (!buffer)
> + die(_("commit object has invalid format"));
In line with my previous comment, I think this should be more like:
if (!buffer) {
static char v_o_i_d[] = "\n\n";
buffer = v_o_i_d;
warning(_("commit lacks end-of-header. A broken Git emulation?"");
}
The warning is of course optional.
^ permalink raw reply
* Re: gitweb: (potential) problems with new installation
From: Jakub Narebski @ 2012-02-28 17:25 UTC (permalink / raw)
To: git; +Cc: Ramsay Jones
[Cc-ed to git mailing list, again this time without HTML]
On Mon, 27 Feb 2012, Ramsay Jones wrote:
> I recently decided to update the gitweb installation on my laptop, since
> it was still running version 1.5.5! (also, the cgit I have installed is
> about the same vintage ...)
>
> The version of gitweb I installed was, simply because I had just built
> and tested it, the version included in the pu branch as of a couple of
> days ago (commit 8544a26).
>
> First, I should say that I had to modify the script, and move the static
> directory out of cgi-bin, in order to get it to work.
You should never have to modify generated gitweb.cgi script; that is what
configuration file, gitweb_config.perl by default, is for. It is well
documented in gitweb.conf(5) manpage, which in turn is referenced in
gitweb(1) manpage... at least with modern git.
Note also that you can specify where to put static files (page
prerequisites) during "make install"... though that it would not obviate
need to create and edit gitweb configuration file.
> However, this is
> not something new; I had to do the same with the previous version. The
> problem is obviously an apache configuration problem, which I tried to
> fix last time and (having spent *lots* of effort) gave up on; the main
> symptom of the problem is that apache attempts to *exec* any file in
> cgi-bin (e.g. gitweb.css, git-logo.png, git-favicon.png, etc.) which
> fills up the apache error logs with "permission denied" errors while
> trying to exec.
Strange. Which version of Apache are you using, and how do relevant
parts of Apache configuration (httpd.conf etc.) look like?
If you use ScriptAlias directive, or ExecCGI option, then the problem
might be executable permissions -- Apache shouldn't execute scripts
without execute permission set as CGI scripts... errr... are you running
httpd as root?
You can move to using "AddHandler cgi-script .cgi" instead.
>
> Anyway, I moved the static directory into a gitweb directory (as a sibling
> to cgi-bin) and changed the paths in gitweb.cgi by prefixing "../gitweb/".
>
> Now that I had working gitweb, I played with some of the new features and
> noticed a few problems ... I suspect that most of the problems are caused
> by my *old* version of firefox, which is:
>
> firefox version 2.0.0.3
>
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) \
> Gecko/20061201 Firefox/2.0.0.3
I have even older web browser:
Mozilla 1.7.12
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) \
Gecko/20050923 MultiZilla/1.7.9.0a
> However, I hope the following may be of use; even if only to document a
> version of firefox that is not supported by gitweb. ;-)
>
> 1. The new date timezone pop-up; The pop-up window comes up directly
> over the date, so you can no longer read it, and once you have set
> the desired timezone, it can not be dismissed. (including the x
> button on the window). The only way to remove it is to refresh the
> page, which makes it a little less that useful ... :-D
Hmmm... I have tested this code on Mozilla 1.7.12, and on modern at the time
of writing Firefox, Chrome, IE, and ancient Konqueror without encountering
any problems.
Could you at minimum check for JavaScript errors using JavaScript Console
(clearing it and reloading gitweb page if needed)? Please provide line
where error is with a bit of context (around 3 lines).
Note also that as workaround you can simply turn off this feature: put
the following line in gitweb configuration file:
$feature{'javascript-timezone'}{'default'} = [];
> 2. The error console shows a repeated warning about the css file, like
> so:
>
> Warning: Error in parsing value for property 'display'. \
> Declaration dropped.
> Source File: http://localhost/gitweb/static/gitweb.css
> Line: 621
>
> which corresponds to the following in gitweb.css:
>
> div.remote {
> margin: .5em;
> border: 1px solid #d9d8d1;
> display: inline-block; <-- line 621
> }
This is probably caused by the fact that your web browser doesn't
understand this value of 'display' property because it is too old,
and does not implement CSS2.1 fully.
9.2.4 The 'display' property
inline-block
This value causes an element to generate an inline-level block
container. The inside of an inline-block is formatted as a block
box, and the element itself is formatted as an atomic inline-level
box.
Nb. this is probably not necessary, gitweb looks just fine without it.
> 3. I mis-typed an search term into the project search box and didn't
> see the error message displayed by firefox as I expected (maybe
> incorrectly?). Firefox displayed:
>
> XML Parsing Error: xml declaration not at start of external entity
> Location: http://localhost/cgi-bin/gitweb.cgi?a=project_list&\
> s=*git.*%5C.git&btnS=Search
> Line Number 30, Column 1:
> <?xml version="1.0" encoding="utf-8"?>
> ^
It is the problem with older Firefoxes, namely that with XHTML DTD and
with application/xhtml+xml mimetype it enters strict XML compliance mode.
If webpage is not well-formed XML it would display XML error page instead.
It is enough that there is some whitespace before <?xml ... ?> processing
instruction... which might make for intermittent and annoying to squash
Heisenbug.
But in some cases it might happen if there are warnings or errors created
by Perl itself and converted to web page by CGI::Carp (fatalsToBrowser).
> The apache error log looked correct:
>
> [Sun Feb 26 16:50:52 2012] gitweb.cgi: Quantifier follows nothing \
> in regex; marked by <-- HERE in m/* <-- HERE git.*\.git/ at \
> /var/www/cgi-bin/gitweb.cgi line 3084.
Hmmm... if we don't use regexp search, then all metacharacters should be
quoted, including leading '*'. Strange.
If you did use regexp search, then it is a real issue, and it is not
something I have thought about. Your search term
*git.*\.git
is invalid regexp, because '*' quantifier which means zero or more
occurrences does not follow any term. Valid regexp is
.*git.*\.git
or just
git.*\.git
Gitweb should probably check that regexp is valid before using it.
Thanks for reporting this; I'll try to fix it shortly.
> Whereas the page source did look wrong. Just in case it would be of
> use, I have included the page source below.
Thanks.
Damn, I thought that I have that issue squashed! The problem is when
there is error thrown or warning triggered when gitweb already printed
part of page. The error handler then writes error page from beginning
inside existing page... not good.
I'll try to look at this.
> As I said above, I suspect these problems are caused by my relatively old
> Linux installation (I keep meaning to get around to updating, but I must
> say that I don't like the new Ubuntu, although Linux Mint 12 looks quite
> good ...).
>
> Having said that, ignoring the new features, gitweb is working fine for
> me (I only installed it in the first place to test it out ...). Also, the
> above represents (literally) only ten minutes of playing around with the
> new features, without having read any documentation or code. So, if I have
> mis-understood how something should work, then sorry for the noise! :(
>
> Hope this helps.
>
> ATB,
> Ramsay Jones
[cut example HTML output]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] commit: allow {--amend|-c foo} when {HEAD|foo} has empty message
From: Junio C Hamano @ 2012-02-28 17:21 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, Thomas Rast, git
In-Reply-To: <87haybco1j.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@inf.ethz.ch> writes:
> So either there's a lot to be fixed, or fsck needs to catch this.
Your experiment with hash-object aside (that is like saying "I can write
garbage with a disk editor, and now OS cannot read from that directory"),
if somebody manages to create a commit without any body, it is clear that
the user wanted to record no body. I think all code that tries to run
strstr("\n\n") and increment the resulting pointer by two to find the
beginning of the body should behave as if it found one and the result
pointed at a NUL. Rejecting with fsck does not help anybody, as it
happens after the fact.
^ permalink raw reply
* Re: git (commit|tag) atomicity
From: Jon Jagger @ 2012-02-28 17:12 UTC (permalink / raw)
To: git
In-Reply-To: <4F4D04F4.80905@ira.uka.de>
On Tue, Feb 28, 2012 at 4:46 PM, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> On 28.02.2012 16:40, Jon Jagger wrote:
>>
>> Hi,
>> I don't know a lot about git - I use it as a tool behind
>> http://cyber-dojo.com
>> which is an online coding dojo server.
>> I have a quick question...
>> If I do a
>> git commit ....
>> in one thread and a
>> git tag | sort -g
>> in another thread is the output of the git tag guaranteed to be atomic?
>
>
> Can a "git commit" add or remove tags? AFAIK it can't and so the two
> commands don't conflict in any way.
Sorry, I failed to ask the question I really wanted to ask...
I mean in one thread
git tag -m 'AAA' BBB HEAD
and in another thread
git tag | sort -g
and the question is whether the output of the git tag|sort -g command
is guaranteed to be from before the git tag -m... or from after the
git tag -m... but not "interleaved" in any way....
Cheers
Jon
^ permalink raw reply
* Re: git (commit|tag) atomicity
From: Holger Hellmuth @ 2012-02-28 16:46 UTC (permalink / raw)
To: Jon Jagger; +Cc: git
In-Reply-To: <CADWOt=j8gJvr88eNAfoYq_qGQvG6M_k-9MCuof_DRrH0sHRVCA@mail.gmail.com>
On 28.02.2012 16:40, Jon Jagger wrote:
> Hi,
> I don't know a lot about git - I use it as a tool behind
> http://cyber-dojo.com
> which is an online coding dojo server.
> I have a quick question...
> If I do a
> git commit ....
> in one thread and a
> git tag | sort -g
> in another thread is the output of the git tag guaranteed to be atomic?
Can a "git commit" add or remove tags? AFAIK it can't and so the two
commands don't conflict in any way.
^ permalink raw reply
* Re: [PATCH v2] Perform cheaper connectivity check when pack is used as medium
From: Andreas Ericsson @ 2012-02-28 15:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nguyễn Thái Ngọc Duy, git, Junio C Hamano
In-Reply-To: <4F4CF58A.9090502@viscovery.net>
On 02/28/2012 04:40 PM, Johannes Sixt wrote:
> Am 2/28/2012 14:18, schrieb Nguyễn Thái Ngọc Duy:
>> Without the patch:
>> $ time git fetch file:///home/pclouds/w/git/.git
>> remote: Counting objects: 125638, done.
>> remote: Compressing objects: 100% (33201/33201), done.
> ...
>> With the patch:
>> $ time git fetch file:///home/pclouds/w/git/.git
>> remote: Counting objects: 125647, done.
>> remote: Compressing objects: 100% (33209/33209), done.
>
> It is a bit irritating that the number are different when they should be
> identical...
>
I found it odd as well, but since the latter shows a larger object
count and a shorter time, I disregarded it and considered it some
evidence that he pushed this patch to that repo.
Since commit created 6 blobs, 2 trees and 1 commit object, and the
latter has 9 objects more, I assume that's what happened anyways.
As such, I think we can live with the small discrepancy. Also note
that the latter post had slower transfer rate. That also skews the
comparison somewhat, but again it's in favour of the patch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH v2] Perform cheaper connectivity check when pack is used as medium
From: Johannes Sixt @ 2012-02-28 15:40 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1330435109-4437-1-git-send-email-pclouds@gmail.com>
Am 2/28/2012 14:18, schrieb Nguyễn Thái Ngọc Duy:
> Without the patch:
> $ time git fetch file:///home/pclouds/w/git/.git
> remote: Counting objects: 125638, done.
> remote: Compressing objects: 100% (33201/33201), done.
...
> With the patch:
> $ time git fetch file:///home/pclouds/w/git/.git
> remote: Counting objects: 125647, done.
> remote: Compressing objects: 100% (33209/33209), done.
It is a bit irritating that the number are different when they should be
identical...
-- Hannes
^ permalink raw reply
* git (commit|tag) atomicity
From: Jon Jagger @ 2012-02-28 15:40 UTC (permalink / raw)
To: git
Hi,
I don't know a lot about git - I use it as a tool behind
http://cyber-dojo.com
which is an online coding dojo server.
I have a quick question...
If I do a
git commit ....
in one thread and a
git tag | sort -g
in another thread is the output of the git tag guaranteed to be atomic?
That is, the output will be from before the git commit or after it but
not a mixture?
Logically, I assume so but cannot find anything definitive on google
or in my git books or from the lips of my friends.
Thanks for any help
Jon Jagger
^ permalink raw reply
* [PATCH] Documentation: use {asterisk} in rev-list-options.txt when needed
From: Carlos Martín Nieto @ 2012-02-28 15:35 UTC (permalink / raw)
To: git
Text between to '*' is emphasized in AsciiDoc which made the
glob-related explanations in rev-list-options.txt very confusing, as
the rendered text would be missing two asterisks and the text between
them would be emphasized instead.
Use '{asterisk}' where needed to make them show up as asterisks in the
rendered text.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
Documentation/rev-list-options.txt | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 39e6207..6a4b635 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -117,27 +117,27 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit).
Pretend as if all the refs in `refs/heads` are listed
on the command line as '<commit>'. If '<pattern>' is given, limit
branches to ones matching given shell glob. If pattern lacks '?',
- '*', or '[', '/*' at the end is implied.
+ '{asterisk}', or '[', '/{asterisk}' at the end is implied.
--tags[=<pattern>]::
Pretend as if all the refs in `refs/tags` are listed
on the command line as '<commit>'. If '<pattern>' is given, limit
- tags to ones matching given shell glob. If pattern lacks '?', '*',
- or '[', '/*' at the end is implied.
+ tags to ones matching given shell glob. If pattern lacks '?', '{asterisk}',
+ or '[', '/{asterisk}' at the end is implied.
--remotes[=<pattern>]::
Pretend as if all the refs in `refs/remotes` are listed
on the command line as '<commit>'. If '<pattern>' is given, limit
remote-tracking branches to ones matching given shell glob.
- If pattern lacks '?', '*', or '[', '/*' at the end is implied.
+ If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied.
--glob=<glob-pattern>::
Pretend as if all the refs matching shell glob '<glob-pattern>'
are listed on the command line as '<commit>'. Leading 'refs/',
- is automatically prepended if missing. If pattern lacks '?', '*',
- or '[', '/*' at the end is implied.
+ is automatically prepended if missing. If pattern lacks '?', '{asterisk}',
+ or '[', '/{asterisk}' at the end is implied.
--ignore-missing::
--
1.7.9.2.3.g4346f
^ permalink raw reply related
* Re: [PATCH] branch: don't assume the merge filter ref exists
From: Carlos Martín Nieto @ 2012-02-28 15:14 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Bernhard Reutner-Fischer, git
In-Reply-To: <20120227194305.GE1600@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Mon, 2012-02-27 at 14:43 -0500, Jeff King wrote:
> On Mon, Feb 27, 2012 at 11:33:49AM -0800, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > > You would also get NULL if the object exists but is not a commit. Maybe:
> > >
> > > die("object '%s' does not point to a commit", ...)
> > >
> > > would be better? It covers the wrong-type case, and is still technically
> > > true when the object does not exist.
> >
> > For this particular message I like the above a lot better. The output
> > from "git grep -e 'invalid object' -e 'bad object'" seems to show that
> > the use of both are fairly evenly distributed.
>
> It looks like "bad object" generally comes from parse_object failing,
> which makes sense. It either means object corruption or you fed a full
> 40-char sha1 that didn't exist (which, if you are being that specific,
> probably is an indication of broken-ness in your repository).
Right. Another version of the fix I was playing with used parse_object
after get_sha1 in opt_parse_merge_filter to make sure there that the
objects did exist, so I copied that error message for this patch.
I see Junio's already squashed this in, and it's certainly a better
message.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Thomas Rast @ 2012-02-28 14:34 UTC (permalink / raw)
To: Nelson Benitez Leon; +Cc: git, peff, sam.vilain, sam
In-Reply-To: <4F4CEB5D.5020808@seap.minhap.es>
Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> On 02/28/2012 01:19 PM, Thomas Rast wrote:
>>
>> * Why is this needed? Does git's use of libcurl ignore http_proxy? [1]
>> seems to indicate that libcurl respects <protocol>_proxy
>> automatically.
>
> It could not be needed, because, as you noted, curl already reads it, but then we will
> loose the feature on patch [3/3] because if $http_proxy has username but no password
> curl will not ask you for the password.. instead if we read it we could detect that,
> and ask for the password.
Ok. An explanation along these lines should definitely go into the
commit message!
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 1/3] http: authenticate on NTLM proxies and others suppported, by CuRL
From: Thomas Rast @ 2012-02-28 14:32 UTC (permalink / raw)
To: Nelson Benitez Leon; +Cc: git, peff, sam, sam.vilain
In-Reply-To: <4F4CCE01.8080300@seap.minhap.es>
Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> - if (curl_http_proxy)
> + if (curl_http_proxy) {
> curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
> + curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
> + }
There was another attempt at doing the same very recently:
http://thread.gmane.org/gmane.comp.version-control.git/191140
I could swear there was a second one, but apparently that was you.
Neither you nor Marco submitter have so far answered the question I
raised in
http://thread.gmane.org/gmane.comp.version-control.git/191155
which can be summarized as: please make a case -- and put it in the
message! -- for or against making this configurable. Is there a speed
tradeoff? (However, you could steal some of Daniel Stenberg's
reasoning!)
Note that Marco (the submitter in the first one) has told me privately
that he could not pursue this further right now, so I suppose he'd be
happy if you could finish it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH 2/2] rev-list: fix --verify-objects --quiet becoming --objects
From: Nguyễn Thái Ngọc Duy @ 2012-02-28 14:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1330437600-9425-1-git-send-email-pclouds@gmail.com>
When --quiet is specified, finish_object() is called instead of
show_object(). The latter is in charge of --verify-objects and
will be skipped if --quiet is specified.
Move the code up to finish_object(). Also pass the quiet flag along
and make it always call show_* functions to avoid similar problems in
future.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
bisect.h | 4 ++--
builtin/rev-list.c | 26 +++++++++++++++-----------
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/bisect.h b/bisect.h
index b06949e..ec3c3ff 100644
--- a/bisect.h
+++ b/bisect.h
@@ -15,12 +15,12 @@ extern void print_commit_list(struct commit_list *list,
const char *format_cur,
const char *format_last);
-/* bisect_show_flags flags in struct rev_list_info */
#define BISECT_SHOW_ALL (1<<0)
+#define REV_LIST_QUIET (1<<1)
struct rev_list_info {
struct rev_info *revs;
- int bisect_show_flags;
+ int flags;
int show_timestamp;
int hdr_termination;
const char *header_prefix;
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 7a3f820..4c4d404 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -52,6 +52,11 @@ static void show_commit(struct commit *commit, void *data)
struct rev_list_info *info = data;
struct rev_info *revs = info->revs;
+ if (info->flags & REV_LIST_QUIET) {
+ finish_commit(commit, data);
+ return;
+ }
+
graph_show_commit(revs->graph);
if (revs->count) {
@@ -172,8 +177,11 @@ static void finish_object(struct object *obj,
const struct name_path *path, const char *name,
void *cb_data)
{
+ struct rev_list_info *info = cb_data;
if (obj->type == OBJ_BLOB && !has_sha1_file(obj->sha1))
die("missing blob object '%s'", sha1_to_hex(obj->sha1));
+ if (info->revs->verify_objects && !obj->parsed && obj->type != OBJ_COMMIT)
+ parse_object(obj->sha1);
}
static void show_object(struct object *obj,
@@ -181,10 +189,9 @@ static void show_object(struct object *obj,
void *cb_data)
{
struct rev_list_info *info = cb_data;
-
finish_object(obj, path, component, cb_data);
- if (info->revs->verify_objects && !obj->parsed && obj->type != OBJ_COMMIT)
- parse_object(obj->sha1);
+ if (info->flags & REV_LIST_QUIET)
+ return;
show_object_with_name(stdout, obj, path, component);
}
@@ -254,7 +261,7 @@ static void print_var_int(const char *var, int val)
static int show_bisect_vars(struct rev_list_info *info, int reaches, int all)
{
- int cnt, flags = info->bisect_show_flags;
+ int cnt, flags = info->flags;
char hex[41] = "";
struct commit_list *tried;
struct rev_info *revs = info->revs;
@@ -305,7 +312,6 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
int bisect_list = 0;
int bisect_show_vars = 0;
int bisect_find_all = 0;
- int quiet = 0;
git_config(git_default_config, NULL);
init_revisions(&revs, prefix);
@@ -318,7 +324,8 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (revs.bisect)
bisect_list = 1;
- quiet = DIFF_OPT_TST(&revs.diffopt, QUICK);
+ if (DIFF_OPT_TST(&revs.diffopt, QUICK))
+ info.flags |= REV_LIST_QUIET;
for (i = 1 ; i < argc; i++) {
const char *arg = argv[i];
@@ -337,7 +344,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (!strcmp(arg, "--bisect-all")) {
bisect_list = 1;
bisect_find_all = 1;
- info.bisect_show_flags = BISECT_SHOW_ALL;
+ info.flags |= BISECT_SHOW_ALL;
revs.show_decorations = 1;
continue;
}
@@ -388,10 +395,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
return show_bisect_vars(&info, reaches, all);
}
- traverse_commit_list(&revs,
- quiet ? finish_commit : show_commit,
- quiet ? finish_object : show_object,
- &info);
+ traverse_commit_list(&revs, show_commit, show_object, &info);
if (revs.count) {
if (revs.left_right && revs.cherry_mark)
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH 1/2] rev-list: remove BISECT_SHOW_TRIED flag
From: Nguyễn Thái Ngọc Duy @ 2012-02-28 13:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
Since c99f069 (bisect--helper: remove "--next-vars" option as it is
now useless - 2009-04-21), this flag has always been off. Remove the
flag and all related code.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
bisect.h | 1 -
builtin/rev-list.c | 12 +-----------
2 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/bisect.h b/bisect.h
index 22f2e4d..b06949e 100644
--- a/bisect.h
+++ b/bisect.h
@@ -17,7 +17,6 @@ extern void print_commit_list(struct commit_list *list,
/* bisect_show_flags flags in struct rev_list_info */
#define BISECT_SHOW_ALL (1<<0)
-#define BISECT_SHOW_TRIED (1<<1)
struct rev_list_info {
struct rev_info *revs;
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 264e3ae..7a3f820 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -242,13 +242,6 @@ void print_commit_list(struct commit_list *list,
}
}
-static void show_tried_revs(struct commit_list *tried)
-{
- printf("bisect_tried='");
- print_commit_list(tried, "%s|", "%s");
- printf("'\n");
-}
-
static void print_var_str(const char *var, const char *val)
{
printf("%s='%s'\n", var, val);
@@ -266,7 +259,7 @@ static int show_bisect_vars(struct rev_list_info *info, int reaches, int all)
struct commit_list *tried;
struct rev_info *revs = info->revs;
- if (!revs->commits && !(flags & BISECT_SHOW_TRIED))
+ if (!revs->commits)
return 1;
revs->commits = filter_skipped(revs->commits, &tried,
@@ -294,9 +287,6 @@ static int show_bisect_vars(struct rev_list_info *info, int reaches, int all)
printf("------\n");
}
- if (flags & BISECT_SHOW_TRIED)
- show_tried_revs(tried);
-
print_var_str("bisect_rev", hex);
print_var_int("bisect_nr", cnt - 1);
print_var_int("bisect_good", all - reaches - 1);
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Nelson Benitez Leon @ 2012-02-28 14:57 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, peff, sam.vilain, sam
In-Reply-To: <878vjn8823.fsf@thomas.inf.ethz.ch>
On 02/28/2012 01:19 PM, Thomas Rast wrote:
> Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
>
>> + if (!curl_http_proxy) {
>> + const char *env_proxy;
>> + env_proxy = getenv("HTTP_PROXY");
>> + if (!env_proxy) {
>> + env_proxy = getenv("http_proxy");
>> + }
>> + if (env_proxy) {
>> + curl_http_proxy = xstrdup(env_proxy);
>> + }
>> + }
>
> Admittedly I'm mostly clueless about curl, but while investigating the
> NTLM login thing I noticed this bit in curl(1):
>
> ENVIRONMENT
> The environment variables can be specified in lower case or upper
> case. The lower case version has precedence. http_proxy is an
> exception as it is only available in lower case.
>
> Which raises the questions:
>
> * Why is this needed? Does git's use of libcurl ignore http_proxy? [1]
> seems to indicate that libcurl respects <protocol>_proxy
> automatically.
It could not be needed, because, as you noted, curl already reads it, but then we will
loose the feature on patch [3/3] because if $http_proxy has username but no password
curl will not ask you for the password.. instead if we read it we could detect that,
and ask for the password.
As a minor note if we let curl to read it then patch [1/1] has
to be changed to include CURLOPT_PROXYAUTH unconditionally (ie. out of the
'if (curl_http_proxy)'). I personally like the feature of not writing my password
on $http_proxy at the cost of reading the env vars ourselves.
>
> * Why do you (need to?) support HTTP_PROXY when curl doesn't?
I found somewhere documented HTTP_PROXY as well as http_proxy, but I've just checked
wget[1] and also only supports http_proxy so I think we can discard it as is not widely
used..
[1] http://www.gnu.org/software/wget/manual/html_node/Proxies.html
>
>
> [1] http://curl.haxx.se/libcurl/c/libcurl-tutorial.html, "Environment Variables"
>
^ permalink raw reply
* [PATCH v2] Perform cheaper connectivity check when pack is used as medium
From: Nguyễn Thái Ngọc Duy @ 2012-02-28 13:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vmx849ma8.fsf@alter.siamese.dyndns.org>
When we fetch or push, usually "git rev-list --verify-objects --not
--all --stdin" is used to make sure that there are no gaps between
existing refs and new refs. --verify-objects calls parse_object(),
which internally calls check_sha1_signature() to verify object content
matches its SHA-1 signature.
check_sha1_signature() is an expensive operation, especially when new
refs are far away from existing ones because all objects in between
are re-hashed. However, if we receive new objects by pack, we can
skip the operation because packs themselves do not contain SHA-1
signatures. All signatures are recreated by unpack-objects/index-pack's
hashing objects in the pack, which we can trust.
Detect pack transfer cases and turn --verify-objects to --objects.
--objects is similar to --verify-objects except that it does not call
check_sha1_signature().
As an (extreme) example, a repository is created with only one commit:
e83c516 (Initial revision of "git", the information manager from hell
- 2005-04-07). The rest of git.git is fetched on top. Without the
patch:
$ time git fetch file:///home/pclouds/w/git/.git
remote: Counting objects: 125638, done.
remote: Compressing objects: 100% (33201/33201), done.
remote: Total 125638 (delta 92568), reused 123517 (delta 90743)
Receiving objects: 100% (125638/125638), 34.58 MiB | 8.07 MiB/s, done.
Resolving deltas: 100% (92568/92568), done.
From file:///home/pclouds/w/git/
* branch HEAD -> FETCH_HEAD
real 1m30.972s
user 1m31.410s
sys 0m1.757s
With the patch:
$ time git fetch file:///home/pclouds/w/git/.git
remote: Counting objects: 125647, done.
remote: Compressing objects: 100% (33209/33209), done.
remote: Total 125647 (delta 92576), reused 123516 (delta 90744)
Receiving objects: 100% (125647/125647), 34.58 MiB | 7.99 MiB/s, done.
Resolving deltas: 100% (92576/92576), done.
From file:///home/pclouds/w/git/
* branch HEAD -> FETCH_HEAD
real 0m51.456s
user 0m52.737s
sys 0m1.548s
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
combine "quiet" and "strict" to a flag word
builtin/fetch.c | 14 +++++++++-----
connected.c | 11 +++++++----
connected.h | 6 +++++-
transport.c | 5 +++++
transport.h | 1 +
5 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 65f5f9b..70c9ca3 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -368,7 +368,7 @@ static int iterate_ref_map(void *cb_data, unsigned char sha1[20])
}
static int store_updated_refs(const char *raw_url, const char *remote_name,
- struct ref *ref_map)
+ struct ref *ref_map, int use_pack)
{
FILE *fp;
struct commit *commit;
@@ -389,7 +389,9 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
url = xstrdup("foreign");
rm = ref_map;
- if (check_everything_connected(iterate_ref_map, 0, &rm)) {
+ if (check_everything_connected(iterate_ref_map,
+ use_pack ? 0 : CHECK_CONNECT_STRICT,
+ &rm)) {
rc = error(_("%s did not send all necessary objects\n"), url);
goto abort;
}
@@ -516,7 +518,8 @@ static int quickfetch(struct ref *ref_map)
*/
if (depth)
return -1;
- return check_everything_connected(iterate_ref_map, 1, &rm);
+ return check_everything_connected(iterate_ref_map,
+ CHECK_CONNECT_QUIET, &rm);
}
static int fetch_refs(struct transport *transport, struct ref *ref_map)
@@ -526,8 +529,9 @@ static int fetch_refs(struct transport *transport, struct ref *ref_map)
ret = transport_fetch_refs(transport, ref_map);
if (!ret)
ret |= store_updated_refs(transport->url,
- transport->remote->name,
- ref_map);
+ transport->remote->name,
+ ref_map,
+ is_pack_transport(transport));
transport_unlock_pack(transport);
return ret;
}
diff --git a/connected.c b/connected.c
index d762423..9df357d 100644
--- a/connected.c
+++ b/connected.c
@@ -14,10 +14,11 @@
*
* Returns 0 if everything is connected, non-zero otherwise.
*/
-int check_everything_connected(sha1_iterate_fn fn, int quiet, void *cb_data)
+int check_everything_connected(sha1_iterate_fn fn, unsigned int flags,
+ void *cb_data)
{
struct child_process rev_list;
- const char *argv[] = {"rev-list", "--verify-objects",
+ const char *argv[] = {"rev-list", "--objects",
"--stdin", "--not", "--all", NULL, NULL};
char commit[41];
unsigned char sha1[20];
@@ -26,7 +27,9 @@ int check_everything_connected(sha1_iterate_fn fn, int quiet, void *cb_data)
if (fn(cb_data, sha1))
return err;
- if (quiet)
+ if (flags & CHECK_CONNECT_STRICT)
+ argv[1] = "--verify-objects";
+ if (flags & CHECK_CONNECT_QUIET)
argv[5] = "--quiet";
memset(&rev_list, 0, sizeof(rev_list));
@@ -34,7 +37,7 @@ int check_everything_connected(sha1_iterate_fn fn, int quiet, void *cb_data)
rev_list.git_cmd = 1;
rev_list.in = -1;
rev_list.no_stdout = 1;
- rev_list.no_stderr = quiet;
+ rev_list.no_stderr = flags & CHECK_CONNECT_QUIET;
if (start_command(&rev_list))
return error(_("Could not run 'git rev-list'"));
diff --git a/connected.h b/connected.h
index 7e4585a..52636b9 100644
--- a/connected.h
+++ b/connected.h
@@ -1,6 +1,9 @@
#ifndef CONNECTED_H
#define CONNECTED_H
+#define CHECK_CONNECT_QUIET 1
+#define CHECK_CONNECT_STRICT 2
+
/*
* Take callback data, and return next object name in the buffer.
* When called after returning the name for the last object, return -1
@@ -15,6 +18,7 @@ typedef int (*sha1_iterate_fn)(void *, unsigned char [20]);
*
* Return 0 if Ok, non zero otherwise (i.e. some missing objects)
*/
-extern int check_everything_connected(sha1_iterate_fn, int quiet, void *cb_data);
+extern int check_everything_connected(sha1_iterate_fn, unsigned int flags,
+ void *cb_data);
#endif /* CONNECTED_H */
diff --git a/transport.c b/transport.c
index 181f8f2..cd5e0ca 100644
--- a/transport.c
+++ b/transport.c
@@ -1248,3 +1248,8 @@ void for_each_alternate_ref(alternate_ref_fn fn, void *data)
cb.data = data;
foreach_alt_odb(refs_from_alternate_cb, &cb);
}
+
+int is_pack_transport(const struct transport *transport)
+{
+ return transport->fetch == fetch_refs_via_pack;
+}
diff --git a/transport.h b/transport.h
index ce99ef8..7cf72ff 100644
--- a/transport.h
+++ b/transport.h
@@ -150,6 +150,7 @@ int transport_disconnect(struct transport *transport);
char *transport_anonymize_url(const char *url);
void transport_take_over(struct transport *transport,
struct child_process *child);
+int is_pack_transport(const struct transport *transport);
int transport_connect(struct transport *transport, const char *name,
const char *exec, int fd[2]);
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH 0/3] http: proxy support improvements
From: Nelson Benitez Leon @ 2012-02-28 12:50 UTC (permalink / raw)
To: git; +Cc: peff, sam, sam.vilain
[cc'ing jeff king and sam vilain as per git-blame they've
work on http auth and proxy code..]
Hi, my initial motivation for this patch was to add NTLM proxy
authentication so I could 'git clone' from inside my employers
network, but apart from doing that, I also added two more features,
so, so I'm sending three patches which implement the following features:
- Support NTLM proxy authentication (as well as other authentication
methods) by setting CURLOPT_PROXYAUTH[1] to CURLAUTH_ANY.
- Look up environment vars http_proxy and HTTP_PROXY in case git
http.proxy config option is not set. This supports system wide proxy
support in terminals.
- Support proxy urls with username but without a password, in which
case we interactively ask for the password (as it's already done in
http auth code). This makes possible to not have the password written
down in git config files or in env vars.
Thanks!
[1] http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTPROXYAUTH
Nelson Benitez Leon (3):
http: authenticate on NTLM proxies and others suppported by CuRL
http: try standard proxy env vars when http.proxy config option is
not set
http: when proxy url has username but no password, ask for password
http.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 48 insertions(+), 2 deletions(-)
--
1.7.7.6
^ permalink raw reply
* [PATCH 1/3] http: authenticate on NTLM proxies and others suppported, by CuRL
From: Nelson Benitez Leon @ 2012-02-28 12:52 UTC (permalink / raw)
To: git, peff, sam, sam.vilain
Signed-off-by: Nelson Benitez Leon <nbenitezl@gmail.com>
---
http.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index 0ffd79c..8ac8eb6 100644
--- a/http.c
+++ b/http.c
@@ -295,8 +295,10 @@ static CURL *get_curl_handle(void)
if (curl_ftp_no_epsv)
curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
- if (curl_http_proxy)
+ if (curl_http_proxy) {
curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
+ curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
+ }
return result;
}
--
1.7.7.6
^ permalink raw reply related
* Announcing 3 git docs: Best Practices, fixing mistakes, post-production editing
From: Seth Robertson @ 2012-02-28 13:04 UTC (permalink / raw)
To: git
I would like to announce three git documents I have written which
others (primarily on #git) have thought to be very useful, and so I
would like to share them with the wider community.
Commit Often, Perfect Later, Publish Once: Git Best Practices
----------------------------------------------------------------------
http://sethrobertson.github.com/GitBestPractices
This first document covers a variety of topics, providing references
and recommendations for using git. These best practices have been
built up through decades of professional software management and
development, years of git usage, and countless hours helping people on
#git.
Table of Contents:
Do read about git On Sausage Making
Do commit early and often Do keep up to date
Don't panic Do periodic maintenance
Do backups Do enforce Standards
Don't change published history Do use useful tools
Do choose a workflow Do integrate with external tools
Do divide work into repositories Miscellaneous "Do"s
Do make useful commit messages Miscellaneous "Don't"s
On undoing, fixing, or removing commits or mistakes in git
----------------------------------------------------------------------
http://sethrobertson.github.com/GitFixUm
This next document covers the process of recovering from mistakes made
either while or when using git. It is a choose-your-own-adventure(1)
style document which asks a series of questions to try and understand
exactly what you did and what you want to do. Currently it provides
twenty different solutions to various problems I have seen people
have. This was primarily developed to stop answering the same
questions over and over again in #git, and worse, providing the wrong
answers when questioners either failed to provide critical information
or totally misunderstood what was going on.
Post-Production Editing using Git
----------------------------------------------------------------------
http://sethrobertson.github.com/GitPostProduction
This most recent document covers the topic of how to use git to make
your commits appear like they were made perfectly to the outside
world. Doing so is something which is required by some projects, is
recommended in gitworkflows(7) and the best practices document (On
Sausage Making), and is a major feature of git. However, I have not
found good documentation on exactly how to use git to accomplish this.
The git-rebase man page is quite extensive, but also fairly confusing
to the uninitiated.
I would appreciate comments, suggestions, or contributions for all
three documents.
-Seth Robertson
(1) Not affiliated with Chooseco, LLC's "Choose Your Own
Adventure"â“¡. Good books, but a little light on the details of
recovering from git merge errors.
^ permalink raw reply
* Re: [RFC PATCH 2a] pretty: detect missing \n\n in commit message
From: Nguyen Thai Ngoc Duy @ 2012-02-28 12:56 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <5234ba4babd28d9430750d227d629b4d4386b131.1330425111.git.trast@student.ethz.ch>
On Tue, Feb 28, 2012 at 5:37 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> get_header()'s exit condition is finding the \n\n that separates the
> commit header from its message. If such a double newline is not
> present, it segfaults. Catch this case and die().
I'd prefer a gentler approach: if there's no \n\n, accept that this
commit has no body. I think I encountered such commits in the test
suite when I tried to convert commit encoding partially and made the
assumption that \n\n must exist.
--
Duy
^ 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