Felipe Contreras writes:
> Junio C Hamano wrote:
>> * fc/complete-aliased-push (2014-04-09) 1 commit
>> - completion: fix completing args of aliased "push", "fetch", etc.
>>
>> Will merge to 'next'.
>>
>>
>> * fc/remote-helper-fixes (2014-04-09) 4 commits
>> - remote-bzr: include authors fi
On 04/11/2014 09:25 PM, Junio C Hamano wrote:
> [...]
> The motion is about this:
>
> Outside people, like the party who approached us about putting
> our logo on their trinket, seem to associate that logo we see on
> git-scm.com today with our project, but we never officially said
>
Duy Nguyen writes:
> On Sat, Apr 12, 2014 at 3:43 AM, Junio C Hamano wrote:
>> Having said that, nobody sane would be running two simultaneous
>> operations that are clearly write-oriented competing with each other
>> against the same index file.
>
> When it comes to racing, sanity does not matt
On Sat, Apr 12, 2014 at 3:43 AM, Junio C Hamano wrote:
> Having said that, nobody sane would be running two simultaneous
> operations that are clearly write-oriented competing with each other
> against the same index file.
When it comes to racing, sanity does not matter much. People could
just do
zsh seems to have a bug while redirecting the stderr of the 'read'
command:
% read foo 2> /dev/null < foo
zsh: no such file or directory: foo
Which causes errors to be displayed when certain files are missing.
Let's add a convenience function to manually check if the file is
readable before cal
Junio C Hamano wrote:
> * fc/complete-aliased-push (2014-04-09) 1 commit
> - completion: fix completing args of aliased "push", "fetch", etc.
>
> Will merge to 'next'.
>
>
> * fc/remote-helper-fixes (2014-04-09) 4 commits
> - remote-bzr: include authors field in pushed commits
Before you do,
So that the committer is reset properly.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/test-bzr.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/test-bzr.sh
b/contrib/remote-helpers/test-bzr.sh
index 1e53ff9..f5c90a4 100755
--- a/contrib
On Fri, Apr 11, 2014 at 01:43:47PM -0700, Junio C Hamano wrote:
> Having said that, nobody sane would be running two simultaneous
> operations that are clearly write-oriented competing with each other
> against the same index file. So in that sense that can be done as a
> less urgent follow-up for
On Apr 11, 2014, at 10:30, Matthieu Moy wrote:
"Kyle J. McKay" writes:
There are already nested functions with file inclusion between both
levels of nesting in git-rebase--interactive.sh and git-rebase--
merge.sh now, so it's not introducing anything new.
OK, so it's less serious than I thou
Ronnie Sahlberg writes:
> refs.c:ref_transaction_commit() intermingles doing updates and checks with
> actually applying changes to the refs in loops that abort on error.
> This is done one ref at a time and means that if an error is detected that
> will fail the operation partway through the lis
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The number of topics cooking in 'next' has been shrinking, and the
cycle is getting long. Hopefully we will have -rc0 late next week to
close th
Hi,
the Git for Windows team just released version 1.9.2 of the
Windows-specific installers.
New Features
* Comes with Git 1.9.2 plus Windows-specific patches.
* Custom installer settings can be saved and loaded, for unsupervised
installation on batches of machines (msysGit PR #168).
* Comes wi
Ronnie Sahlberg writes:
> int commit_ref_lock(struct ref_lock *lock)
> {
> + if (lock->delete_ref) {
> + int flag = lock->delete_flag;
> +
> + if (!(flag & REF_ISPACKED) || flag & REF_ISSYMREF) {
> + /* loose */
> + int err, i
Junio:
On Fri, Apr 11, 2014 at 3:25 PM, Junio C Hamano wrote:
> The pages at https://git.wiki.kernel.org/index.php/Main_Page are
> done primarily by developers, and between the two logos on that
> page, the one that appears inside the page under "Main Page" header
> has long been the logo that Gi
"Kyle J. McKay" writes:
> Instead, we can use the [...] construct to defeat the special meaning
> of the '?' character and match it exactly in a way that works for the
> FreeBSD /bin/sh as well as other POSIX /bin/sh implementations.
>
> Changing the example like so:
>
> x='one?two?three'
> echo
Junio C Hamano writes:
> Yeah, I was hoping that the real write codepath (as opposed to "this
> is read only and we read the index without holding a lock---now we
> noticed that the index needs refreshing, and we know how the
> resulting refreshed index should look like, perhaps we can write it
>
Change the function write_ref_sha1() to just write the ref but not
commit the ref or the lockfile.
Add a new function commit_ref_lock() that will commit the change done by
a previous write_ref_sha1().
Update all callers of write_ref_sha1() to call commit_ref_lock().
The new pattern for updating a
During a transaction commit we will both update and delete refs.
Since both update and delete now use the same pattern
lock = lock_ref_sha1_basic() (or varient of)
write_ref_sha1(lock)/delete_ref_loose(lock)
unlock_ref(lock) | commit_ref_lock(lock)
we can now simplify ref_transaction_
Change delete_ref_loose()) to just flag that a ref is to be deleted but do
not actually unlink the files.
Change commit_ref_lock() so that it will unlink refs that are flagged for
deletion.
Change all callers of delete_ref_loose() to explicitely call commit_ref_lock()
to commit the deletion.
The n
refs.c:ref_transaction_commit() intermingles doing updates and checks with
actually applying changes to the refs in loops that abort on error.
This is done one ref at a time and means that if an error is detected that
will fail the operation partway through the list of refs to update we
will end up
On 2014-04-11 22.20, Frank Ammeter wrote:
> I’m not a git expert and this might be the wrong place to ask this question,
> so please send me somewhere else if I’m in the wrong place.
>
> I asked the same question on stack overflow, but didn’t get any response:
> http://stackoverflow.com/questions/
Max Horn wrote:
> On 11.04.2014, at 20:56, Felipe Contreras wrote:
> > Max Horn wrote:
> >> Come back when you have facts, as opposed to the illusion that you are the
> >> spokesperson of the (apparently silent) majority of Git users.
> >
> > Facts:
> >
> > 1) A hunk that removed (-) is represen
I’m not a git expert and this might be the wrong place to ask this question,
so please send me somewhere else if I’m in the wrong place.
I asked the same question on stack overflow, but didn’t get any response:
http://stackoverflow.com/questions/22823004/files-incorrectly-reported-modified-git-att
Junio C Hamano wrote:
> Jeff King writes:
>
> > For instance, it looks like your @{publish} requires config like:
> >
> > [branch "master"]
> > pushremote = foo
> > push = refs/heads/bar
> >
> > to operate. Setting "pushremote" affects what "git push" does; it will
> > go to the "foo" remot
Nice.
Once this is in I can add transactional support to receive-pack.
On Mon, Apr 7, 2014 at 6:47 AM, Michael Haggerty wrote:
> Here is v3. It is also available on GitHub [1].
>
> Thanks to Junio and Brad for their comments about v2. I think I have
> addressed all of your comments (except for
Felipe Contreras writes:
> The publish branch is the branch the user wants to push to, akin to the
> upstream branch, which is the branch the user wants to use as a
> baseline. It overrides other configurations, such as push.default, and
> remote..push.
>
> The upstream branch is:
>
> branch.$n
On Fri, Apr 11, 2014 at 12:25 PM, Junio C Hamano wrote:
> Please help us by letting us answer "Yup, that is a logo (among
> others) that represents our project, and we are OK with you
> using it to help promote our project" instead.
>
> That is what I meant by "our official logo" in t
Junio C Hamano wrote:
> In any case, this motion is not about "let's declare the logo we see
> on git-scm.com today as _the_ official one".
Phew. :)
[...]
> Please help us by letting us answer "Yup, that is a logo (among
> others) that represents our project, and we are OK with you
>
Matthieu Moy wrote:
> Felipe Contreras writes:
>
> > My patch series only affects push.default=simple, perhaps you have a
> > different configuration.
>
> Good catch. I have push.default=upstream (essentially for compatibility
> with old Git versions, I'd prefer simple actually).
>
> > Maybe we
Jeff King writes:
> The git-scm.com page is mostly targeted at end users: what is it, how do
> I get it, where is the documentation. Things like a logo repository, or
> developer information is spread across various wikis and other sites.
> If there's interest, we can make "dev.git-scm.com" for s
Jeff King writes:
> For instance, it looks like your @{publish} requires config like:
>
> [branch "master"]
> pushremote = foo
> push = refs/heads/bar
>
> to operate. Setting "pushremote" affects what "git push" does; it will
> go to the "foo" remote.
OK, and the same thing would happen if
Duy Nguyen writes:
> On Fri, Apr 11, 2014 at 2:28 AM, Junio C Hamano wrote:
>> Yiannis Marangos writes:
>>
>>> + n = xpread(fd, sha1, 20, st.st_size - 20);
>>> + if (n != 20)
>>> + goto out;
>>
>> I think it is possible for pread(2) to give you a short-read.
>>
>> The existi
Jeff King writes:
> On Fri, Apr 11, 2014 at 01:24:02AM -0700, Kyle J. McKay wrote:
>
>> Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the
>> t7001-mv test has used "cp -a" to perform a copy in several of the
>> tests.
>>
>> However, the "-a" option is not required for a POSIX cp
On 11.04.2014, at 20:56, Felipe Contreras wrote:
> Max Horn wrote:
>> On 11.04.2014, at 17:21, Felipe Contreras wrote:
>>> Max Horn wrote:
On 11.04.2014, at 15:29, Felipe Contreras
wrote:
> Max Horn wrote:
>
> You don't think red represent an oldness in Git? Whereas gre
Max Horn wrote:
> On 11.04.2014, at 17:21, Felipe Contreras wrote:
> > Max Horn wrote:
> >> On 11.04.2014, at 15:29, Felipe Contreras
> >> wrote:
> >>> Max Horn wrote:
> >>>
> >>> You don't think red represent an oldness in Git? Whereas green
> >>> represents progress?
> >>
> >> No, I don't th
Felipe Contreras writes:
> * Override other configurations (such as push.default)
I think I convinced myself that this is the right way to go since my
last message. After all, "push.default" is, by definition, just a
default.
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @
>
On 11.04.2014, at 17:21, Felipe Contreras wrote:
> Max Horn wrote:
>> On 11.04.2014, at 15:29, Felipe Contreras wrote:
>>> Max Horn wrote:
>>>
>>> You don't think red represent an oldness in Git? Whereas green
>>> represents progress?
>>
>> No, I don't think that.
>
> Then you belong to t
On 11.04.2014, at 17:39, Philippe Vaucher wrote:
>>> You don't think red represent an oldness in Git? Whereas green
>>> represents progress?
>>
>> No, I don't think that.
>>
>> Perhaps you think that, but if that is the case, it is based on your own
>> sociocultural background. Hey, and let's
Attn: Sir / Madam,
We have a job offer available for qualified applicants.
You do not need to work from an office.
You can work from home and earn ($2000)monthly.
Contact us immediately on:
Allen Lee
eunibli...@gmail.com
Fabric Land Inc.
--
To unsubscribe from this list: send the line "unsubscribe
The 'upstream' variable doesn't hold an "upstream", but a branch, so
make it clearer.
Signed-off-by: Felipe Contreras
---
sha1_name.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 6fca869..906f09d 100644
--- a/sha1_
It does it along the upstream branch, if any.
* publish ... [master, gh/publish: ahead 1] ...
master ... [master, gh/master] ...
Signed-off-by: Felipe Contreras
---
builtin/branch.c | 17 -
t/t6040-tracking-info.sh | 5 +++--
2 files changed, 19 insertions(+), 3 dele
Signed-off-by: Felipe Contreras
---
Documentation/git-branch.txt | 11 +++
branch.c | 44 +
branch.h | 2 ++
builtin/branch.c | 57 ++---
t/t3200-branch.sh| 76
Signed-off-by: Felipe Contreras
---
Documentation/revisions.txt | 4
sha1_name.c | 49 -
t/t1508-at-combinations.sh | 5 +
3 files changed, 40 insertions(+), 18 deletions(-)
diff --git a/Documentation/revisions.txt b/Documen
It's more efficient to check for the braces first.
Signed-off-by: Felipe Contreras
---
sha1_name.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 906f09d..aa3f3e0 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -417,7 +417,7 @@ stati
To setup publish tracking branch, like 'git branch --set-publish'.
Signed-off-by: Felipe Contreras
---
Documentation/git-push.txt | 9 +-
builtin/push.c | 2 ++
t/t5534-push-publish.sh| 70 ++
transport.c| 28 +
We shouldn't modify the commits; it screws the following tests.
Signed-off-by: Felipe Contreras
---
t/t5516-fetch-push.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 67e0ab3..f4cf0db 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fe
As it has been discussed before, our support for triangular workflows is
lacking, and the following patch series aims to improve that situation.
We have the concept of upstream branch (e.g. 'origin/master') which is to where
our topic branches eventually should be merged to, so it makes sense that
The publish branch is the branch the user wants to push to, akin to the
upstream branch, which is the branch the user wants to use as a
baseline. It overrides other configurations, such as push.default, and
remote..push.
The upstream branch is:
branch.$name.remote
branch.$name.merge
The publ
This crossed my path recently via the fossil mailing list
http://git-man-page-generator.lokaltog.net/
but I thought folks here might enjoy the humor :-)
(and I hadn't seen mention of it here on the list yet)
-tkc
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
"Kyle J. McKay" writes:
> There are already nested functions with file inclusion between both
> levels of nesting in git-rebase--interactive.sh and git-rebase--
> merge.sh now, so it's not introducing anything new.
OK, so it's less serious than I thought. But still, we're introducing a
function
Just noticed that clicking on the big "Free and Open Source" button at
http://git-scm.com/about
brings up a contentless page. I don't know what sort of content
should be here and is now missing, but I figured those responsible
might want to populate that section.
-tkc
--
To unsubscribe from
Holger Hellmuth wrote:
> Am 11.04.2014 17:39, schrieb Philippe Vaucher:
> >FWIW, I think if you made a poll and asked which color is the most
> >"positive" between green and red, the vast majority of people would
> >say "green". Examples could be traffic green lights vs red lights, or
>
> Coca-Col
Felipe Contreras writes:
> My patch series only affects push.default=simple, perhaps you have a
> different configuration.
Good catch. I have push.default=upstream (essentially for compatibility
with old Git versions, I'd prefer simple actually).
> Maybe we want the publish branch to override a
Karsten Blees writes:
> Additionally, orange/red alerts and attracts the eye while green is
> calming, uninteresting. Imagine a page with five different SCM
> logos. If you want git to stand out, choose orange/red. If you want
> git to be overlooked choose green.
How about using the "blink" attr
Am 09.04.2014 18:43, schrieb Felipe Contreras:
> Junio C Hamano wrote:
>> - To officially adopt the logo that appears on the "project
>>home page" as our "project logo".
>
> I have made my objections to that logo before, but here it goes again: bright
> red is a horrible color for a logo, as
On 2014-04-11 13:32, Javier Domingo Cansino wrote:
> I have never thought on that logo as the Git logo (the red one), and
> thought it was [1]. Mainly because the logo itself has git inside.
> [1] Git logo:
> http://git-osx-installer.googlecode.com/files/GitLogo.jpg --
Like Javier, I too assumed
Am 11.04.2014 17:39, schrieb Philippe Vaucher:
FWIW, I think if you made a poll and asked which color is the most
"positive" between green and red, the vast majority of people would
say "green". Examples could be traffic green lights vs red lights, or
Coca-Cola uses red. So red is refreshing an
Am 11.04.2014 17:14, schrieb Max Horn:
More between "privacy" (or perhaps "personal safety"? think: dissident coder?) vs.
"feature that is useful to some people".
Well, at least the reason mentioned in the gmane citation about knowing
if it was 2 am for them, is strange. Did anyone ever chec
On 04/09/2014 06:43 PM, Felipe Contreras wrote:
> Junio C Hamano wrote:
>> - To officially adopt the logo that appears on the "project
>>home page" as our "project logo".
>
> I have made my objections to that logo before, but here it goes again: bright
> red is a horrible color for a logo, as
On Fri, Apr 11, 2014 at 09:47:09AM +0200, Torsten Bögershausen wrote:
> 6. process A applies a commit:
> - read the index into memory
> - take the lock
> - update the index file on disc
> - release the lock
So here we can have race condition. Maybe we should implement Duy
> FWIW, I think if you made a poll and asked which color is the most
> "positive" between green and red, the vast majority of people would
> say "green". Examples could be traffic green lights vs red lights, or
> that in nature quiet & peaceful usually involves green while
> danger/action involves
> > You don't think red represent an oldness in Git? Whereas green
> > represents progress?
>
> No, I don't think that.
>
> Perhaps you think that, but if that is the case, it is based on your own
> sociocultural background. Hey, and let's not forget that supposedly 8% or so
> of all males are re
Vincent van Ravesteijn wrote:
> On Fri, Apr 11, 2014 at 3:24 PM, Felipe Contreras
> wrote:
> >
> > Moreover, even the black ones have the issue I already mentioned; they
> > picture the equivalent of two root commits (with no parents) that are
> > immediately merged, and the history continues, but
Max Horn wrote:
> On 11.04.2014, at 15:29, Felipe Contreras wrote:
> > Max Horn wrote:
> >
> > You don't think red represent an oldness in Git? Whereas green
> > represents progress?
>
> No, I don't think that.
Then you belong to the minority of Git users. Those of us that see
patches day and n
From: "Holger Hellmuth"
To: "Michael Haggerty"
Cc: "Mahmoud Asshole" ;
If you look at "Mahmoud's" email address, it is from
http://10minutemail.com/ 'the best disposable e-mail service.'.
So it looks like s/he knew what they were doing when venting their
spleen.
It would have been nicer
On 11.04.2014, at 15:19, Holger Hellmuth wrote:
> Am 11.04.2014 13:08, schrieb Michael Haggerty:
>> On 04/09/2014 10:50 PM, Mahmoud Asshole wrote:
>>> [...]
>>
>> Please conduct your discussions here in a civil tone. It is both more
>> pleasant for all involved and also more likely to elicit a
On 11.04.2014, at 15:29, Felipe Contreras wrote:
> Max Horn wrote:
>> As for the logo, I think it's nice and simple,
>
> You don't think red represent an oldness in Git? Whereas green
> represents progress?
No, I don't think that.
Perhaps you think that, but if that is the case, it is based o
Matthieu Moy wrote:
> Felipe Contreras writes:
>
> > As it has been discussed before, our support for triangular workflows is
> > lacking, and the following patch series aims to improve that situation.
>
> I'm not a heavy user of triangular workflow, so I'm not in the best
> position to comment
On Apr 11, 2014, at 01:48, Matthieu Moy wrote:
"Kyle J. McKay" writes:
If script2.sh is changed to this:
# script2.sh fixed
main() {
if [ 5 -gt 3 ]; then
return 5
fi
case bad in *)
echo always shows
esac
echo should not get here
On Fri, Apr 11, 2014 at 3:24 PM, Felipe Contreras
wrote:
>
> Moreover, even the black ones have the issue I already mentioned; they
> picture the equivalent of two root commits (with no parents) that are
> immediately merged, and the history continues, but who is interested in
> the initial commit
Jeff King wrote:
> On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote:
>
> > > I noticed that this only picks up a publish-branch if
> > > branch.*.pushremote is configured. What happened to the case when
> > > remote.pushdefault is configured?
> >
> > What happens when branch.*.rem
Felipe Contreras writes:
> Secondly, the logos that are not black, are bright red, which is
> horrible; not only do they look bad in almost every situation due to the
> contrast, but in a Git's mindeset red implies old, a minus, the hunk
> removed, an error, which is not good.
Actually, the best
On Apr 11, 2014, at 04:43, Jeff King wrote:
> On Fri, Apr 11, 2014 at 01:24:02AM -0700, Kyle J. McKay wrote:
>
>> Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the
>> t7001-mv test has used "cp -a" to perform a copy in several of the
>> tests.
>>
>> However, the "-a" option is not r
Max Horn wrote:
> As for the logo, I think it's nice and simple,
You don't think red represent an oldness in Git? Whereas green
represents progress?
> and based on experience I think that for every logo you'll find people
> who object to it.
So we should just accept any logo without thinking abo
Jeff King wrote:
> On Thu, Apr 10, 2014 at 10:24:24AM +1000, Andrew Ardill wrote:
>
> > It's normal for an organisation to have a collection of logos to
> > choose from, with one 'official' version. For example, a black and
> > white version is useful for print. Similarly, it's useful to have a
>
Am 11.04.2014 13:08, schrieb Michael Haggerty:
On 04/09/2014 10:50 PM, Mahmoud Asshole wrote:
[...]
Please conduct your discussions here in a civil tone. It is both more
pleasant for all involved and also more likely to elicit a response. I
hardly think that the "waste" of 12 bytes in every
This commit adds custom log_read and log_draw functions that utilize
the diff stat drawing functions from the diff module. The absence of
the triple hyphen separator prevents direct usage of the diff drawing
functions directly.
Signed-Off-By: Kumar Appaiah
---
src/log.c | 62
Signed-off-by: Kumar Appaiah
---
include/tig/diff.h | 1 +
src/diff.c | 30 ++
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/include/tig/diff.h b/include/tig/diff.h
index ba40386..16299fe 100644
--- a/include/tig/diff.h
+++ b/include/tig/dif
Signed-off-by: Kumar Appaiah
---
include/tig/diff.h | 1 +
src/diff.c | 27 ++-
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/include/tig/diff.h b/include/tig/diff.h
index be325c4..ba40386 100644
--- a/include/tig/diff.h
+++ b/include/tig/diff.h
These patches add colourization to the log view. They reuse the diff
stat drawing functions from the diff module directly.
Kumar Appaiah (3):
diff: Move diff stat addition to a common function
diff: Move diff stat drawing to a common function
log: Colour the diff stat
include/tig/diff.h |
My two cents: I like git-scm.com quite a bit. As for the logo, I think it's
nice and simple, and based on experience I think that for every logo you'll
find people who object to it. E.g. the red color of the log on git-scm.com
looks great to me, while I dislike e.g. the color variation Felipe is
On 8 April 2014 16:47, Olivier LE ROY wrote:
> Hello,
>
> I have a project under SVN with contains empty directories.
>
> I would like to move this project on a Git server, still handling empty
> directories.
>
> The solution: put a .gitignore file in each empty directory to have them
> recogniz
On Fri, Apr 11, 2014 at 01:24:02AM -0700, Kyle J. McKay wrote:
> Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the
> t7001-mv test has used "cp -a" to perform a copy in several of the
> tests.
>
> However, the "-a" option is not required for a POSIX cp utility and
> some platforms
On Thu, Apr 10, 2014 at 10:24:24AM +1000, Andrew Ardill wrote:
> It's normal for an organisation to have a collection of logos to
> choose from, with one 'official' version. For example, a black and
> white version is useful for print. Similarly, it's useful to have a
> couple of different contras
I have never thought on that logo as the Git logo (the red one), and
thought it was [1]. Mainly because the logo itself has git inside.
I have to agree with David Kastrup on that I see no connection to git
only by the image (red one). Maybe is because I am accustomed to the
older one[1] I started
On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote:
> > I noticed that this only picks up a publish-branch if
> > branch.*.pushremote is configured. What happened to the case when
> > remote.pushdefault is configured?
>
> What happens when branch.*.remote is not configured for @{ups
On 04/09/2014 10:50 PM, Mahmoud Asshole wrote:
> [...]
Please conduct your discussions here in a civil tone. It is both more
pleasant for all involved and also more likely to elicit a response. I
hardly think that the "waste" of 12 bytes in every commit is an act of
stupidity so inexcusable that
On Fri, Apr 11, 2014 at 2:28 AM, Junio C Hamano wrote:
> +static int verify_index_from(const struct index_state *istate, const char
> *path)
> +{
> + int fd;
> + ssize_t n;
> + struct stat st;
> + unsigned char sha1[20];
> +
> + if (!istate->initialized)
> +
Felipe Contreras writes:
> As it has been discussed before, our support for triangular workflows is
> lacking, and the following patch series aims to improve that situation.
I'm not a heavy user of triangular workflow, so I'm not in the best
position to comment (and I have no time for a real rev
"Kyle J. McKay" writes:
> If script2.sh is changed to this:
>
> # script2.sh fixed
> main() {
> if [ 5 -gt 3 ]; then
> return 5
> fi
> case bad in *)
> echo always shows
> esac
> echo should not get here
> ! :
> }
> m
Since fd0a8c2e (first appearing in v1.7.0), the
t/t5560-http-backend-noserver.sh test has used a backslash escape
inside a ${} expansion in order to specify a literal '?' character.
Unfortunately the FreeBSD /bin/sh does not interpret this correctly.
In a POSIX compliant shell, the following:
x=
Since a1549e10, 15d4bf2e and 01a1e646 (first appearing in v1.8.4) the
git-rebase--*.sh scripts have used a "return" to return from the "dot"
command that runs them. While this is allowed by POSIX, the FreeBSD
/bin/sh utility behaves poorly under some circumstances when such a
"return" is executed.
This patch series words around the FreeBSD /bin/sh problems that cause rebase
to fail on FreeBSD as well as test t5560-http-backend-noserver.
The rebase issue was first introduced in Git v1.8.4 which started using the
"return" statement to return from a "dot" command script where the "dot"
command
This reverts commit 99855ddf4bd319cd06a0524e755ab1c1b7d39f3b.
The workaround 99855ddf introduced to deal with problematic
"return" statements in scripts run by "dot" commands located
inside functions only handles one part of the problem. The
issue has now been addressed by not using "return" stat
Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the
t7001-mv test has used "cp -a" to perform a copy in several of the
tests.
However, the "-a" option is not required for a POSIX cp utility and
some platforms' cp utilities do not support it.
The POSIX equivalent of -a is -R -P -p.
On 2014-04-10 21.28, Junio C Hamano wrote:
> Yiannis Marangos writes:
>
>> +n = xpread(fd, sha1, 20, st.st_size - 20);
>> +if (n != 20)
>> +goto out;
>
> I think it is possible for pread(2) to give you a short-read.
>
> The existing callers of emulated mmap and index-pack ar
> This finally happened again. Here's what the reflog looks like:
>
> 2805f68 master@{0}: push
> 96eebc0 master@{1}: push
> 75bd4a6 master@{2}: push
> abc30da master@{3}: push
> eba874f master@{4}: push
> 10981e7 master@{5}: push
> 76b3957 master@{6}: push
> 2e3ea06 master@{7}: push
> 9d4e778 mast
97 matches
Mail list logo
